Vieraskäyttäjät (guest users) ovat voineet jo pitkään käyttää (ei muokata) Power Appseja. Tämä on varsin hyödyllinen ominaisuus.

Vieraskäyttöön liittyy kuitenkin muutamia rajoituksia, ongelmia ja kommervenkkeja, jotka on hyvä tietää ennen aloittamista. Käydään tällä kertaa näistä ne keskeisimmät läpi.

Vieraskäyttäjän kutsuminen (invite)

Ensimmäiseksi vieras tulee lisätä käyttäjäksi organisaation ympäristöön (tenant), mikäli hän ei sitä jo ole. Riippuen asetuksista, tämän voi tehdä usealla eri tavalla (SharePoint, Teams, Azure portaali).

Alla esimerkki kutsun teosta Azure portaalista.

Kutsuminen itsessään ei ole ongelma, vaan varmistuminen siitä että vastaanottaja lukee ja hyväksyy lähetetyn kutsun. Se ei nimittäin näytä kauhean houkuttelevalta. Varsinkin mikäli kutsu tulee täysin tuntemattomalta henkilöltä.

Varsinainen hyväksyminen tehdään linkin takaa aukeavasta dialogista.

Onneksi isoimmilla organisaatioilla on usein räätälöidyt kutsuviestit, sekä toimiva prosessi jolla varmistetaan kutsuttujen löytäminen perille ympäristön käyttäjiksi.

Vieraskäyttäjän lisenssi

Vieraskäyttäjä tarvitsee usein myös lisenssin. Tyypilliset skenariot ovat

  • Power Appsilla muokattu SharePoint-listan lomake: ei lisenssiä
  • Power Apps, jonka tietolähteenä SharePoint-lista. Ratkaisussa ei käytetä premium-yhdistimiä: Power Apps for Office 365
  • Power Apps, jonka tietolähteenä SharePoint-lista. Ratkaisussa käytetään premium-yhdistimiä: Power Apps per User tai Power Apps per app plan
  • Power Apps, jonka tietolähteenä Dataverse: Power Apps per User tai Power Apps per app plan
  • Mallipohjainen Power Apps: Power Apps per User tai Power Apps per app plan

Vieraskäyttäjä voi hyödyntää oman organisaationsa Power Apps for Office 365 ja Power Apps per User -lisenssiä. Power Apps per app plan -lisenssejä ei voi tuoda mukanaan toiseen organisaatioon.

Office365Users -yhdistimen (connector) käyttö

Usein jossain kohtaa sovelluksessa valitaan organisaation käyttäjä. Esimerkiksi tilauksen hyväksyjä. Tähän käytetään Office365Users-yhdistintä, joka sidotaan kontrolliin. Alla comboboxiin.

Kätevää.

Vieraskäyttäjällä ei kuitenkaan ole oikeuksia hakea käyttäjien tietoja ympäristössä.

Kiertotie – SharePoint-lista

Ongelmaan löytyy ikiaikainen kiertotie. Nimittäin henkilövalinnan toteuttaminen SharePoint-listan henkilökentän avulla.

Luodaan SharePoint-lista, joka sisältää ainoastaan henkilö-tyyppisen sarakkeen.

Jaetaan tämä lista kaikille vieraskäyttäjille.

Lisätään Power Appsiin lomake, jolla voi lisätä uuden rivin tälle SharePoint-listalle. Lomakkeella esitetään ainoastaan henkilö-kenttä. Mitään riviä ei koskaan lisätä, vaan lomaketta käytetään ainoastaan henkilön poimimiseen.

Näin meillä on henkilövalinta, joka toimii myös vieraskäyttäjillä.

SQL Server ja Entra ID autentikointi

Lisätään sovellukseemme SQL-yhteys.

Ensimmäinen vaihtoehto (Service Principal) ei ole (vielä) tuettu Power Appsissa. Kaksi viimeistä taas koskee on-premise SQL palvelimia. Jäljelle jäävät

  • Azure AD integrated: Tietokantaan annetaan käyttöoikeus käyttäjäryhmälle tai yksittäisille käyttäjille. Tunnistautuminen hoituu Entra ID:llä.
  • SQL Server integrated: Käytetään tietokantaan luotuja logineja (käyttäjätunnus + salasana). Sovelluksen käyttäjät käyttävät tietokantaa samalla käyttäjätunnuksella.

Näistä ensimmäinen on se suositeltu tapa. Mutta se ei toimi vieraskäyttäjillä.

Jäljelle jäävä vaihtoehto nostaa monilla karvat pystyyn. Se on klassinen pelotteluesimerkki Power Platformin tietoturvasta.

Nykyään tämä ei ole ongelma. Power Appsissa on oletuksena päällä jaettujen yhteyksien turvaaminen. Niitä ei pääse enää entiseen tapaan kierrättämään omissa sovelluksissaan.

Mikä käyttäjää vastaava Dataverse-käyttäjä on?

Aikaisemmin tämä aiheutti vieraskäyttäjien kanssa ongelmia. Eli miten löytää sovelluksen käyttäjää vastaava käyttäjä Dataversestä. Dataverse-käyttäjän ensisijainen sähköposti (primary email) on useimmiten sama kuin käyttäjän sähköposti. Muttei aina.

Ongelma poistui, kun Power Appsin käyttäjä-objektiin tuli mukaan EntraObjectId. Sillä hakeminen toimii aina.

constDVUser = LookUp(Users, 'Azure AD Object ID' = User().EntraObjectId);

Onko käyttäjä vieraskäyttäjä?

Joissain tilanteissa on hyvä tietää, onko sovelluksen käyttäjä vieraskäyttäjä. Miten tämän voi selvittää?

Varminta on käyttää Graph APIa

https://graph.microsoft.com/v1.0/users?$filter=id eq 'ffc72146-9ebd-4fa0-affe-ce4e498770c2'&$select=userType

Paluuarvo kertoo onko käyttäjä vieras vai ei (Member vs Guest).

{

    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(userType)",

    "value": [

        {

            "userType": "Guest"

        }

    ]

}

Toinen tapa on luottaa Dataverse-käyttäjän (userPrincipalName) nimeen (User Name).

LookUp(Users, 'Azure AD Object ID' = User().EntraObjectId).'User Name'

Ja sieltä löytyvään #EXT# merkkijonoon.

timo.pertila_forwardforever.com#EXT#@PertilaMVP.onmicrosoft.com

Power Platform Tenant Isolation ja Dataverse

Tämä on selvästi bugi, joka tullaan korjaamaan. Mutta nostetaan se silti esille.

Mikäli organisaatiossa on kytketty Power Platform Tenant Isolation päälle, se saattaa estää sovelluksen vieraskäytön kokonaan.

Näin tapahtuu tilanteessa, jossa Power Appsista käsin käynnistetään flow, joka sisältää yhdenkin Dataverse-toiminnon. Tällöin Power Appsia käynnistettäessä pyydetään käyttäjältä suostumus käyttää Dataverseä hänen tunnuksillaan.

Mutta yhteyden luonti ei onnistu.

Virhekin on selvä. Ei ole sallittua.

The request failed with client error: 'Input parameters are invalid. See details for more information. Details:OAuth2Certificate Authorization Flow failed for service Dynamics CRM Online Certificate. Sign-in with Azure Active Directory account timo.pertila_forwardforever.com#EXT#@xxxx.onmicrosoft.com failed, due to a tenant isolation policy for tenant c87c13a2-7547-4218-a01e-06609904d23e.
                If your use case requires a cross-tenant connection, contact your tenant administrator.
                Details: 
                Connection owner tenant: c87c13a2-7547-4218-a01e-06609904d23e,
                Connection sign-in tenant: c87c13a2-7547-4218-a01e-06609904d23e,
                Connector: Microsoft Dataverse.'. The correlation Id is '85f0633b-c88b-466c-be0d-1e567b46351f'.
 
Session ID: c87c13a2-7547-4218-a01e-06609904d23e

Lopputulos on sama riippumatta siitä käytetäänkö flow’ssa käyttäjän omia vai kiinnitettyä yhteyttä.

Dataversen vieraskäytössä ei ole oikeasti mitään ongelmaa. Käyttäjä voi käyttää sitä (käyttöoikeuksiensa rajoissa) vapaasti Power Appsilla. Mutta ei Power Appsiin kytketyllä flow’lla.

Kiertotie – Child flow

Ongelman voi kiertää käynnistämällä Power Appsista flow’n, joka taas käynnistää aliflown (child flow).

Aliflow voi normaaliin tapaan käsitellä myös Dataverseä.

Näin homma toimii, eikä Dataverse-toiminnot flow’ssa estä koko sovelluksen avaamista. Toki nyt kaikki aliflow’n toiminnot suoritetaan kiinteillä yhteyksillä.