Flow’lla on välillä tarpeen tehdä jotain, johon ei löydy valmista yhdistintä (connector). Tämä ei ole ongelma, sillä useimpiin nykyaikaisiin palveluihin on tarjolla rajapinta (API), jolla sitä voi käyttää myös flow’sta.

Tähän tapaan.

Rajapinta voi olla täysin avoin, jolloin tunnistautumisesta ei tarvitse huolehtia. Useimmiten rajapinnalle tulee kuitenkin todentaa olevansa joku, jolla on oikeus käyttää kyseistä palvelua. Microsoftin palvelut käyttävät tähän useimmiten AAD-todennusta.

Tällöin tunnistaudutaan, joko käyttäjänä tai sovelluksena, Azure AD:ta vasten.

Tällä kertaa tutustutaan eri tapoihin käyttää AAD-todennusta hyödyntävää rajapintaa flow’lla.

Esimerkkinä toimikoon Power BI API.

Vaihtehto 1 – HTTP-toiminto ja Service Principal

Ensimmäinen vaihtoehto on käyttää HTTP-toimintoa ja hyödyntää siinä ns. Service Principalia. Emme siis tunnistaudu käyttäjänä, vaan Azure AD:hen rekisteröityneenä sovelluksena.

Internet on pullollaan esimerkkejä tästä. Yksi löytyy tästäkin blogista.

Lyhykäisyydessään Azureen rekisteröidylle sovellukselle luodaan flow’lla valtuus (token).

Luotua valtuutta käytetään sitten varsinaisessa kutsussa todennukseen.

Hyvää

  • Flow’ssa ei käytetä käyttäjän salasanaa -> Se ei ole muiden nähtävillä
  • Osa rajapintojen toiminnoista toimii ainoastaan sovellustason oikeuksilla

Huonoa

  • Mikäli sovelluksen salaisuus (secret) on suoraan flowssa tai se haetaan siihen Keyvault-toiminnolla, se on helposti kaivettavissa esiin
  • Kaikkia rajapinnan toimintoja ei aina voi käyttää sovelluksella, vaan edellytetään kirjautumista käyttäjällä delegoiduin käyttöoikeuksin
  • Sovelluksen salaisuus vanhenee ennemmin tai myöhemmin ja se tulee muistaa päivittää myös flow’hun
  • Edellyttää sovelluksen rekisteröinnin Azure AD:hen

Vaihtehto 2 – HTTP-toiminnon käyttö käyttäjällä

Seuraavassa vaihtoehdossa kirjaudumme AAD-sovellukseen käyttäjänä. Tällöin käytetään sovellukselle määriteltyjä delegoituja käyttöoikeuksia. Eli loppupeleissä kyseisen käyttäjän omia käyttöoikeuksia.

Toteutus on hyvin samannäköinen kuin edellinenkin.

Hyvää

  • Mikäli joku rajapinnan palvelu ei ole käytettävissä sovelluksella, sen saa toimimaan tunnistautumalla käyttäjänä

Huonoa

  • Flow tietää sovelluksen salaisuuden lisäksi myös käyttäjän salasanan. Ei hyvä.
  • Tokenia ei voi muodostaa mikäli käyttäjällä on MFA käytössä (ja miksi ihmeessä ei olisi)
  • Edellyttää sovelluksen rekisteröinnin Azure AD:hen

Vaihtehto 3 – Oma yhdistin (Custom Connector)

Entäpä jos haluamaasi palvelua ei voi käyttää sovelluksena eikä organisaatiossa ole mahdollista luoda tunnuksia ilman MFA:ta?

Voit paketoida rajapinnan omaksi yhdistimeksi (custom connector), jossa määrittelet todennuksen hoituvan Azure Active Directorya vasten.

Ohjeita löytyy jälleen verkosta. Esim: https://learn.microsoft.com/en-us/connectors/custom-connectors/azure-active-directory-authentication

Hyvää

  • Käytettävän tunnuksen salasana tallentuu luotuun yhteyteen (connection), eikä sitä kukaan pääse kaivamaan sieltä itselleen
  • Käytettävällä tunnuksella voi olla MFA käytössä

Huonoa

  • Edellyttää sovelluksen rekisteröinnin Azure AD:hen
  • Saat oman yhdistimen ylläpidettäväksesi
  • Yhteys voi vanheta (expire)

Vaihtehto 4 – HTTP with Azure AD -yhdistin

Tällä kertaa säästin herkkupalan viimeiseksi. Yllättävän harva on tietoinen Power Platformin HTTP with Azure AD yhdistimestä ja sen Invoke an HTTP request -toiminnosta. Tämä johtunee yhdistimen heikosta dokumentaatiosta.

Tällä yhdistimellä voi tehdä API-kutsuja palveluihin, joihin tunnistaudutaan Azure Active Directoryn tai (on-premise AD:n) avulla.

Ja sitähän me olemme tässä kokoajan eri tavoin tehneet.

Lisätään toiminto työnkulkuumme.

Yhteyden luonnissa määritellään, mitä palvelua ko yhteydellä tullaan käyttämään. Ja tässä menee kansalaiskehittäjällä helposti sormi suuhun. Mistä ihmeestä löydän Azure AD Resource URL:in esimerkiksi Power BI:n API:lle?

Helpoiten se onnistuu trendikkäästi chatGPT:llä.

Eli Power BI API:a varten arvot ovat

Painetaan ”Sign In” ja kirjaudutaan halutulla tunnuksella. Tämän jälkeen voi tehdä kutsuja ko palveluun ilman mitään tunnistautumissäätöä. Sen on jo tehty.

Toimii!

Hyvää

  • Käytettävän tunnuksen salasana tallentuu luotuun yhteyteen (connection), sitä ei pääse kaivamaan sieltä esiin
  • Tunnuksella voi olla MFA käytössä
  • Ei tarvetta rekisteröidä omaa sovellusta Azure AD:hen
  • Erinomainen vaihtoehto Microsoftin omien palvelujen käyttöön

Huonoa

  • Ei toimi kaikkien palvelujen eikä kaikkien palvelun kutsujen kanssa
  • Dokumentaatio huonoa. Täytyy vain kokeilla toimiko.
  • Yhteys voi vanheta (expire)
  • Yhteys pitää sisällän tiedon siitä, mitä palvelua ko yhteydellä voi käyttää. Eri palveluiden käyttöön luodut yhteydet menevät helposti sekaisin keskenään

Mitä rajapintoja tällä menetelmällä oikeasti voi käyttää? Yhteydelle tulee luontivaiheessa antaa käytettävän resurssin osoite AAD:ssa (Azure AD Resource URL): Turvallista lienee olettaa, että resurssin tulee AAD:sta myös löytyä. Hyviä kandidaatteja voi selata vaikka rekisteröitävän sovelluksen API-permissions -osiosta.

Täältä muuten löytyy myös se kaivattu Azure AD Resource URL myös.

Älä unohda valmiita yhdistimiä!

Kaikki edellämainitut vaihtoehdot edellyttävät käyttäjältä Power Automate -lisenssiä. Ne nojaavat ns. premium-yhdistimiin.

Flow’sta löytyy myös vakio (standard) -yhdistimiä, joilla voi tehdä kutsuja rajattuihin osiin Microsoftin Graph API:a.

Näitä ovat esimerkiksi seuraavat.

Harmiksemme vastaavaa yhdistintä ei löydy esimerkiksi Power BI API:lle.