Canvas ja model-driven Power Appsien käyttäjinä on jo pitkään voinut olla myös vieraskäyttäjiä (guest users). Kunhan heidät on asianmukaisesti lisensoitu.

Tällä kertaa aiheena onkin Power Appsin jakaminen vieraskäyttäjille. Mutta lisätään hieman vaikeuskerrointa. Haluamme saada vieraskäyttäjät ympäristön käyttäjiksi, ennen kuin heidät päästetään käyttämään sovellusta. Tämä on hyvin tyypillinen tarve. Halutaan esimerkiksi etukäteen määritellä tietueiden omistajuuksia tms.

Mutta onnistuuko tämä? Miten?

Azure AD ryhmät ja vieraan kutsuminen

Aloitetaan aivan alusta. Luodaan vieraskäyttäjien käyttämille ratkaisuille oma ympäristö (environment). Sitä ennen luodaan kaksi AAD-ryhmää.

  • Guest users environment. Tällä määritellään ketkä tenantin käyttäjistä voivat olla kyseisen ympäristön käyttäjiä. Käytännössä tämä ryhmä kytketään luotavaan ympäristöön.
  • Guest users App 1. Tällä taaas hoidetaan sovelluksemme pääsynhallinta (jakaminen) ja käyttöoikeudet (käyttöoikeusroolit). Tämä ryhmä on edellisen ryhmän jäsen.

Nyt kun käyttäjä lisätään sovelluskohtaiseen ryhmään, niin

  • hänestä tulee ympäristön käyttäjä
  • hän pääsee käyttämään sovellustamme

Eli kaikki toimii, kun käyttäjä lisätään yhden AAD-ryhmän jäseneksi.

Lopuksi luodaan kutsu sovellusta käyttävälle vieraskäyttäjälle. Käyttäjä lisätään jo kutsuvaiheessa Guest users App 1 -ryhmään.

Meillä on nyt vieraskäyttäjä valmiina ja oikean ryhmän jäsenenä. Puuttuu ainoastaan sovellus, jota hän käyttää.

Ympäristö ja esimerkkisovellus

Luodaan sovellukselle ympäristö, jonka käyttäjinä ovat ainoastaan Guest users environment -ryhmän käyttäjät.

Sovellus hyödyntää Dataverseä, joten vieraat tarvitsevat lisenssin. Käytetään Power Apps per App -lisenssejä, eli annetaan tarvittava määrä lisenssejä tämän ympäristön käyttöön.

Luodaan sovellusta varten taulu, jonka yhtenä kenttänä on käyttäjä (User). Käytännössä meillä on lista autoja, joiden hallinnoija on joku (vieras)käyttäjistä.

Tehdään vieraskäyttäjille lopuksi canvas Power Apps, joka näyttää luodun taulun tiedot.

Vaihdetaan sovellus käyttämään Per-app -lisenssejä.

Lopuksi jaetaan sovellus Guest users App 1 -ryhmälle. Samalla määritellään käyttäjien saamat käyttöoikeusroolit (security roles).

Jakaminen AAD-ryhmälle luo automaattisesti tiimin Dataverseen.

Näin meillä on

  • Ympäristö, jonka käyttäjiä ovat Guest users environment -ryhmän jäsenet (vieraskäyttäjämme)
  • Yksinkertainen sovellus, joka on jaettu Guest users App 1 -ryhmälle. Ryhmä saa automaattisesti myös käyttöön tarvittavan käyttöoikeusroolin.

Pääsemme vihdoin alkuperäiseen ongelmaamme. Miten saamme käyttäjät populoitua käyttäjät-tauluun, jotta voimme asettaa autoille omistajat ennen kuin vieraskäyttäjät ryhtyvät käyttämään sovellusta?

Käyttäjät eivät valu ympäristöön automaattisesti vaikka ovat oikeiden ryhmien jäseninä. Heiltä nimittäin puuttuu tarvittava lisenssi. Eikä sovelluksen jakaminen heille tee sekään vielä yhtään mitään.

Käyttäjien lisääminen käsin

Voimme lisätä käyttäjät käsin heti kutsujen lähettämisen jälkeen. Tämä ei edellytä että kutsut olisi hyväksytty.

Huoma ettei tämä onnistu, mikäli ympäristölle ole annettu ei ole Power Apps per app -lisenssejä.

Käyttäjän lisäämisen jälkeen voimme lisätä hänet auton omistajaksi. Ennen kuin hän on avannut sovellusta kertaakaan.

Käyttäjä ei kuitenkaan ilmesty AAD-ryhmään pohjautuvaan tiimiimme (joka syntyi automaattisesti kun jaoimme sovelluksen AAD-ryhmälle). Käyttäjä lisätään tiimiin vasta käyttäjän avatessa sovelluksen kyseisestä ympäristöstä.

Käyttäjien lisääminen Flow’lla

Käyttäjien lisääminen käsin vaikuttaa hieman tympeältä. Onneksemme voimme tehdä flow’n, jolla päivitämme Guest users App 1 -ryhmän käyttäjät Dataverseen.

Ajon jälkeen ryhmän jäsenet löytyvät Dataversen käyttäjistä.

Näppärää mikäli tämä tehdään vain kerran. Flow’ssa ei nimittäin ole triggeriä, jolla työnkulun saisi käynnistymään aina kun AAD-ryhmään lisätään uusi jäsen.

Triggeröinti onnistuisi, mikäli ryhmänä käytettäisiin M365-ryhmää. Mutta Power Platform ympäristöön liitettävän ryhmän sisällä olevat M365-ryhmät eivät toimi (ainakaan vielä). Käytännössä jos lisäät ympäristöön liitettävän AAD-ryhmän sisään M365-ryhmän, ei käyttäjä pääse ympäristöön vaikka hän on kyseisen M365-ryhmän jäsen. Hänen tulee olla tämän lisäksi myös ympäristöön liitettävän AAD-ryhmän jäsen.

Kutsun hyväksyminen

Miltä tämä kaikki näyttää vieraskäyttäjän silmin? Ensin hän saa kutsun tulla ympäristön käyttäjäksi.

Kutsun hyväksyminen voi olla käyttäjälle hämmentävä kokemus. Kutsu itsessään on jo hieman pelottavan näköinen.

Kaikenlaisia lupiakin pitää antaa.

Kaiken muun lisäksi edellytämme kaikilta MFA:n käyttöä. Myös vieraskäyttäjiltä.

Seuraavaksi vieras konfiguroi MFA:n käyttöön. Onneksi se on nykyään kohtuullisen helppoa.

Prosessin lopuksi käyttäjä pääsee tyhjälle sivulle. Hämmentävää?

Mutta mitä loppujen lopuksi tapahtuu vieraskäyttäjä hyväksyessä kutsun? Power Platformin näkökulmasta ei yhtään mitään. Käyttäjä ei ilmesty Dataverseen käyttäjäksi. Pelkkä kutsun hyväksyminen ei siis muuta tilannettamme.

Sovelluksen avaaminen

Kunhan vieraskäyttäjä on hyväksynyt kutsun ja hoitanut MFA-velvollisuudet kuntoon, voi hän avata sovelluksen (kunhan hänelle on lähetetty sen osoite).

Sovellus aukeaa nätisti riippumatta siitä, onko käyttäjä lisäytty käsin ympäristön käyttäjäksi etukäteen vai ei. Ellei ole, hänet lisätään käyttäjäksi sovelluksen ensimmäisellä avauskerralla. Samalla hän saa

  • Käyttöoikeusroolit, jotka on määritelty sovelluksen jaon yhteydessä AAD-ryhmälle
  • Power App per App -lisenssin (mikäli niitä on ympäristössä vielä vapaana, muutoin häntä kehoitetaan käynnistämään lisenssin kokeilujakso (trial))

Ja vihdoin käyttäjä ilmestyy myös tiimin jäseneksi.

Yhteenveto

Sovelluksen jakamiseen liittyvät kiemurat eivät eroa käytännössä mitenkään, on käyttäjä sitten tavallinen tai vieraskäyttäjä.

Molemmissa haasteensa tuo, mikäli tarpeena on saada käyttäjät käyttäjä-tauluun ennen kuin he avaavat sovelluksen.

Mikäli riittää, että käyttäjät luodaan ympäristöön vasta kun he käyttävät sovellusta ensimmäistä kertaa, riittää että he ovat jäseninä sopivassa AAD-ryhmässä.

Sisäkkäiset ryhmät toimivat ainoastaan, mikäli ne ovat AAD-ryhmiä. Tämä on tympeää sillä sovelluskohtaiset käyttöoikeudet olisi usein kätevämpää hoitaa pääkäyttäjien toimesta M365-ryhmillä.