Inleiding

  • 10 minuten

Als u Power BI-inhoud in uw app wilt insluiten, moet u de app ontwikkelen om een toegangstoken te verkrijgen. Het type verificatiestroom (en toegangstoken) is afhankelijk van het insluitscenario.

Notitie

Als u meer wilt weten over scenario's voor insluiten, gaat u naar de productmodule Een ingesloten analyse van Power BI selecteren.

Wanneer u een van beide scenario's gebruikt, moet uw app een Azure AD-token verkrijgen. Een Azure AD-token bevat claims voor het identificeren van verleende machtigingen voor de Power BI REST API. Het heeft een verlooptijd, die meestal één uur is. Een geldig Azure AD token moet aanwezig zijn in alle API-bewerkingen.

Een interactieve verificatiestroom gebruiken

Voor het verkrijgen van een Azure AD token voor het scenario Voor uw organisatie gebruikt de app een interactieve verificatiestroom. Een interactieve verificatiestroom betekent dat Azure AD de gebruiker kunnen vragen zich aan te melden met behulp van hun gebruikersnaam en wachtwoord en (mogelijk) met behulp van meervoudige verificatie (MFA). Azure AD kan de gebruiker ook vragen om meer toestemming te verlenen aan resources (vereist bij de eerste aanmelding voor de app).

Notitie

Wanneer de app het gebruik van eenmalige aanmelding (SSO) inschakelt, hoeven gebruikers zich niet elke keer aan te melden wanneer ze deze gebruiken. Tijdens het verificatieproces worden referenties in een sessiecookie in de cache opgeslagen wanneer de gebruiker zich de eerste keer verifieert. De app kan deze referenties in de cache gebruiken totdat ze verlopen, wat standaard na 90 dagen is.

Nadat de app is verkregen, moet het Azure AD-token in de cache worden opgeslagen. De app gebruikt de app vervolgens om Power BI-inhoud in te sluiten waarvoor de gebruiker gemachtigd is om mee te werken.

In de volgende video ziet u het gebruik van een interactieve verificatiestroom.

In les 3 leert u hoe u Azure AD tokens kunt verkrijgen.

Een niet-interactieve verificatiestroom gebruiken

Voor het verkrijgen van een Azure AD token voor het scenario Voor uw klanten gebruikt de app een niet-interactieve verificatiestroom. App-gebruikers hoeven geen Power BI-account te hebben en zelfs wanneer ze dat doen, worden deze accounts niet gebruikt. Een toegewezen Azure AD-identiteit, ook wel de insluitidentiteit genoemd, wordt geverifieerd met Azure AD. Een insluitidentiteit kan een service-principal of een hoofdgebruikersaccount zijn.

Een niet-interactieve verificatiestroom wordt ook wel stille verificatie genoemd. Er wordt geprobeerd een Azure-token te verkrijgen op een manier waarop de verificatieservice de gebruiker niet om aanvullende informatie kan vragen. Zodra de app-gebruiker zich bij uw app verifieert (de app kan elke verificatiemethode gebruiken die u kiest), gebruikt de app de insluitidentiteit om een Azure AD-token te verkrijgen met behulp van een niet-interactieve verificatiestroom.

Zodra uw app een Azure AD-token heeft verkregen, wordt deze in de cache opgeslagen en vervolgens gebruikt om een insluittoken te genereren. Een insluittoken vertegenwoordigt feiten over Power BI-inhoud en hoe u deze kunt openen.

In een insluittoken wordt met name het volgende beschreven:

  • Claims op specifieke Power BI-inhoud.
  • Toegangsniveau, dat u instelt om weer te geven, te maken of te bewerken. (De niveaus voor maken en bewerken zijn alleen van toepassing op Power BI-rapporten.)
  • Levensduur van token, die bepaalt wanneer het token verloopt.
  • Optioneel, een claim naar een doelwerkruimte voor het opslaan van nieuwe rapporten.
  • U kunt desgewenst een of meer effectieve identiteiten gebruiken, zodat Power BI gegevensmachtigingen kan afdwingen.

Notitie

Als u meer wilt weten over effectieve identiteiten, gaat u naar de module Gegevensmachtigingen afdwingen voor ingesloten analyses in Power BI .

Bekijk de volgende video over het gebruik van een niet-interactieve verificatiestroom.

In les 3 leert u hoe u insluittokens kunt verkrijgen.

Een service-principal gebruiken

Uw app kan een service-principal gebruiken om een Azure AD-token te verkrijgen. Een Azure-service-principal is een beveiligingsidentiteit die apps gebruiken. Het definieert het toegangsbeleid en de machtigingen voor de app in de Azure AD tenant, waarbij kernfuncties worden ingeschakeld, zoals app-verificatie tijdens het aanmelden en autorisatie tijdens toegang tot resources. Een service-principal kan worden geverifieerd met behulp van een app-geheim of certificaat. We raden u aan service-principals te beveiligen met behulp van certificaten voor uw productie-apps in plaats van geheime sleutels, omdat dit veiliger is.

Wanneer de insluitidentiteit van uw app een service-principal is, moet een Power BI-tenantbeheerder eerst het volgende doen:

  • Schakel het gebruik van service-principals in.
  • Registreer een beveiligingsgroep die deze bevat.

In de volgende afbeelding ziet u de instellingen voor ontwikkelaars (te vinden in de tenantinstellingen van de beheerportal) waar een Power BI-beheerder service-principals kan inschakelen om Power BI-API's te gebruiken.

Schermopname van de instellingen voor ontwikkelaars met het gebruik van service-principals ingeschakeld.

Belangrijk

Wanneer een beheerder het gebruik van service-principals met Power BI toestaat, worden de Azure AD machtigingen van de app niet meer van kracht. Vanaf dat jaar beheren beheerders de machtigingen van de app in de Power BI-beheerportal.

In Power BI moet de service-principal deel uitmaken van de rol van werkruimtebeheerder of lid om werkruimte-inhoud in te sluiten. Alleen nieuwe werkruimten ondersteunen roltoewijzingen aan een service-principal en persoonlijke werkruimten worden niet ondersteund.

Notitie

Het is niet mogelijk om u aan te melden bij de Power BI-service met behulp van een service-principal.

Zie voor meer informatie:

Een hoofdgebruikersaccount gebruiken

Uw app kan een hoofdgebruikersaccount gebruiken om een AD-token te verkrijgen. Een hoofdgebruikersaccount is een gewone Azure AD gebruiker. In Power BI moet het account behoren tot de rol van werkruimtebeheerder of lid om werkruimte-inhoud in te sluiten. Het moet ook een PPU-licentie (Power BI Pro of Power BI Premium per gebruiker) hebben.

Notitie

Het is niet mogelijk om een hoofdgebruikersaccount te gebruiken om gepagineerde rapporten in te sluiten.

Ingesloten identiteitstypen vergelijken

U wordt aangeraden een service-principal te gebruiken voor productie-apps . Het biedt de hoogste beveiliging en daarom is het de methode die door Azure AD wordt aanbevolen. Het biedt ook ondersteuning voor betere automatisering en schaal en er is minder beheeroverhead. Hiervoor zijn echter Power BI-beheerdersrechten vereist voor het instellen en beheren.

U kunt overwegen om een hoofdgebruikersaccount te gebruiken voor het ontwikkelen of testen van apps. Het is eenvoudig in te stellen en kan zich aanmelden bij de Power BI-service om problemen op te lossen. Er zijn echter kosten aan verbonden omdat hiervoor een Power BI Pro- of PPU-licentie is vereist. Een hoofdgebruikersaccount kan ook geen MFA vereisen.

Samengevat worden in de volgende tabel de twee typen ingesloten identiteiten vergeleken.

Item Service-principal Hoofdgebruikersaccount
objecttype Azure AD Service-principal Gebruiker
Referentiebeheer Geheimen of certificaten gebruiken met periodieke rotatie Regelmatig wachtwoordupdates uitvoeren
Power BI-tenantinstellingen Een Power BI-beheerder moet het gebruik van service-principals toestaan. we raden aan dat service-principals deel uitmaken van een toegewezen beveiligingsgroep Niet van toepassing
Power BI REST API-gebruik Sommige bewerkingen voor beheerders en gegevensstromen worden niet ondersteund; u kunt verificatie van service-principals inschakelen voor alleen-lezen beheer-API's. Alle bewerkingen worden ondersteund
Power BI-service aanmelden Niet ondersteund Ondersteund
Licentieverlening Niet vereist Power BI Pro of PPU
Azure AD aanbeveling Aanbevolen (met name voor productie-apps) Niet aanbevolen (maar is mogelijk geschikt voor ontwikkeling of test-apps)
Aanvullende informatie Kan geen MFA vereisen; Gepagineerde rapporten kunnen niet worden ingesloten