Flow’ta tehtäessä tulee miettiä millä tunnuksella/tunnuksilla mitäkin toimintoja tullaan suorittamaan. Emme (yleensä) halua lähettää käyttäjille sähköpostia tai päivittää ajastetusti SharePoint-listan rivejä omalla tunnuksellamme.

Toimenpiteitä varten luodaan tyypillisesti tähän käyttöön pyhitetty tunnus, ns. palvelutunnus (Service Account). Se on normaali M365-tunnus jolla

  • voi kirjautua sisään Office-palveluun
  • on tyypillisesti oma sähköpostilaatikko ja OneDrive-tila
  • tulee olla tarvittavan tasoinen M365-lisenssi

MFA (Multi-Factor Authentication) aiheuttaa palvelutunnusten kanssa päänvaivaa. MFA on syytä olla aktivoitu, mutta kenen puhelimeen se sidotaan? Yleensä henkilön joka on lomalla sinä ainoana päivänä, kun tunnuksella halutaan kirjautua sisään.

Dataverse tarjoaa palvelutunnus-käyttöön tyylikkäämmän ratkaisun Service Principalin muodossa. Service Principal on ns. sovelluskäyttäjä (Application user), jota ei ole sidottu mihinkään AAD käyttäjätunnukseen.

Katsotaan tällä kertaa miten sellainen luodaan ja miten sitä käytetään.

Azure AD -sovelluksen rekisteröinti

Service Principal käyttää tunnistautumiseen Azure AD -sovellusta. Luodaan sellainen.

Avataan Azure Portalista Azure Active Directory ja sieltä App registration.

Annetaan sovellukselle kuvaava nimi ja painetaan ”Register”

Tunnuksemme tarvitsee oikeudet Dataverseen. Siirrytään API permissions -osioon määrittelemään tarvittavat oikeudet.

Valitaan oikeudet klikkaamalla Add a permission.

Vielä mennään vanhalla nimellä… Eli valitaan Dynamics CRM. Ehkäpä tätä tehdessäsi sen tilalla lukee Dataverse.

Valitaan delegoidut oikeudet (Delegated permissions), ruksataan ainoa tarjolla oleva oikeustaso (user_impersonation) ja klikataan ”Add permissions”.

Oikeudet ovat kunnossa!

Tunnus ja salasana

Azureen rekisteröidyn sovelluksen tunnuksena käytetään Overview-osioista löytyvää Application ID:tä. Ota se (ja Tenant ID) talteen. Tarvitsemme niitä myöhemmin.

Tarvitsemme myös salasanan. Sitä kutsutaan täällä salaisuudeksi (secret).

Siirrytään Certificates & secrets -osioon ja luodaan uusi salaisuus (New client secret). Huomaa että salaisuudella on aina voimassaoloaika.

Kopioi luonnin jälkeen salaisuus talteen (sitä tarvitaan myöhemmin). Tämän jälkeen siihen ei enää pääse käsiksi.

Sovelluksen rekisteröinti on valmis. Seuraavaksi luomme Dataverseen sitä vastaavan tunnuksen.

Dataverse – Sovelluskäyttäjän luominen

Siirrytään Power Platform Admin centeriin. Valitaan ympäristö, johon haluamme Service Principalin luoda (ne ovat ympäristökohtaisia aivan kuten kaikki muutkin Dataversen käyttäjät) ja navigoidaan ympäristön käyttäjiin (Users).

Käyttäjälistalla on linkki sovelluskäyttäjiin (application users). Siirrytään sinne.

Luodaan uusi käyttäjä (New app user).

Käyttäjälle määritellään kolme asiaa

  • mitä Azure AD sovellusta (App) se käyttää
  • mihin (Dataversen) liiketoimintayksikköön (Business Unit) se kuuluu
  • mitä käyttöoikeusrooleja (Security roles) sille annetaan

Mikä siisteintä, Azure AD sovelluksen pääsee valitsemaan listalta.

Valmista!

Service Principalin käyttö

Miten tätä mystistä tunnusta käytetään?

Luodaan ajastettu Flow joka luo uuden rivin Hoodies-tauluun. Haluamme suorittaa toiminnon juuri luodulla Service Principalilla. Valitaan kolmeen pisteen takaa ”Add new connection reference”.

Toisin kuin yleensä, valitaan ikkunan alareunasta ”Connect with Service Principal”.

Täytetään tiedot ja luodaan yhteys (Create).

Testataan toimivuutta suorittamalla Flow.

Ja voila! Rivi on luotu ja sen on luojana on Service Principal.

Yhteenveto

Service Principalit ovat käteviä useasta syystä.

  • Voit suorittaa toimintoja palvelutunnuksella
  • Et tarvitse palvelutunnukselle mitään lisenssiä
  • Voit hyödyntää lisensoimattomien käyttäjien Power Platform pyyntörajoja (Power Platform / Dynamics lisensseistä riippuen 25 000, 50 000 tai 100 000 pyyntöä/24h)
  • Ei tarvitse murehtia MFA:sta

Muista kuitenkin

  • Service Principalilla voi käyttää ainoastaan Dataverseä. Mikäli Flow lähettää lisäksi esimerkiksi viestin Teamsiin, tarvitset todennäköisesti myös palvelutunnuksen, jolla on M365-lisenssi.
  • Lisensoimattomien käyttäjien Power Platform pyyntökapasiteetti on yhteinen kaikille tenantin lisensoimattomille käyttäjille. Dynamics-tiimi ei ole välttämättä tyytyväinen, mikäli innokas Power Platform konsultti käyttää koko tenantin pyyntömäärät ja he jäävät ilman.
  • Azure AD -sovelluksen salaisuus vanhenee, aivan kuten tavallisen käyttäjätunnuksen salasana.