Översikt över autentisering (förhandsversion)
Infrastrukturarbetsbelastningar förlitar sig på integrering med Microsoft Entra-ID för autentisering och auktorisering.
Alla interaktioner mellan arbetsbelastningar och andra Fabric- eller Azure-komponenter måste åtföljas av korrekt autentiseringsstöd för begäranden som tas emot eller skickas. Token som skickas ut måste genereras korrekt och mottagna token måste också verifieras korrekt.
Vi rekommenderar att du bekantar dig med Microsofts identitetsplattform innan du börjar arbeta med Fabric-arbetsbelastningar. Vi rekommenderar också att du går över Microsofts identitetsplattform bästa praxis och rekommendationer.
Flöden
Från arbetsbelastningens klientdel till arbetsbelastningens serverdel
Ett exempel på sådan kommunikation är alla API:er för dataplanet. Den här kommunikationen görs med en ämnestoken (delegerad token).
Information om hur du hämtar en token i arbetsbelastningen FE finns i Autentiserings-API. Se dessutom till att du går över tokenvalidering i översikten över autentisering och auktorisering i serverdelen.
Från infrastrukturresursers serverdel till arbetsbelastningsserverdel
Ett exempel på sådan kommunikation är Skapa arbetsbelastningsobjekt. Den här kommunikationen görs med en SubjectAndApp-token, som är en särskild token som innehåller en apptoken och en ämnestoken kombinerad (se översikten över autentisering och auktorisering i serverdelen för mer information om den här token).
För att kommunikationen ska fungera måste användaren som använder den här kommunikationen ge sitt medgivande till Microsoft Entra-programmet.
Från arbetsbelastningens serverdel till infrastrukturresursernas serverdel
Detta görs med en SubjectAndApp-token för API:er för arbetsbelastningskontroll (till exempel ResolveItemPermissions) eller med en ämnestoken (för andra Infrastruktur-API:er).
Från arbetsbelastningens serverdel till externa tjänster
Ett exempel på sådan kommunikation är att skriva till en Lakehouse-fil. Detta görs med ämnestoken eller en apptoken, beroende på API:et.
Om du planerar att kommunicera med tjänster med hjälp av en ämnestoken kontrollerar du att du är bekant med Å flödens vägnar.
Se självstudien Autentisering för att konfigurera din miljö så att den fungerar med autentisering.
JavaScript-API för autentisering
Fabric-klientdelen erbjuder ett JavaScript-API för Fabric-arbetsbelastningar för att hämta en token för deras program i Microsoft Entra-ID. Innan du arbetar med JavaScript-API:et för autentisering måste du gå över dokumentationen för JavaScript API för autentisering.
Samtycker
Information om varför medgivande krävs finns i Användar- och administratörsmedgivande i Microsoft Entra-ID.
Kommentar
Medgivanden krävs för att CRUD/Jobb ska fungera och för att hämta token mellan klienter.
Hur fungerar medgivanden i Infrastrukturarbetsbelastningar?
För att bevilja ett medgivande för ett visst program skapar Fabric FE en MSAL-instans som konfigurerats med arbetsbelastningens program-ID och ber om en token för det angivna omfånget (additionalScopesToConsent – se AcquireAccessTokenParams).
När du ber om en token med arbetsbelastningsprogrammet för ett specifikt omfång visar Microsoft Entra-ID ett popup-medgivande om den saknas och omdirigerar sedan popup-fönstret till omdirigerings-URI : n som konfigurerats i programmet.
Vanligtvis finns omdirigerings-URI:n i samma domän som sidan som begärde token så att sidan kan komma åt popup-fönstret och stänga den.
I vårt fall finns den inte i samma domän eftersom Fabric begär token och omdirigerings-URI:n för arbetsbelastningen inte finns i infrastrukturresursdomänen, så när dialogrutan medgivande öppnas måste den stängas manuellt efter omdirigering – vi använder inte koden som returneras i redirectUri, och därför omsluter vi den automatiskt (när Microsoft Entra-ID omdirigerar popup-fönstret till omdirigerings-URI:n, stängs).
Du kan se koden/konfigurationen för omdirigerings-URI:n i filen index.ts. Den här filen finns i exemplet Microsoft-Fabric-workload-development-under klientdelsmappen.
Här är ett exempel på ett popup-fönster med medgivande för appen "min arbetsbelastningsapp" och dess beroenden (lagring och Power BI) som vi konfigurerade när vi gick över autentiseringsuppsättningen:
Ett annat sätt att bevilja medgivanden i hemklientorganisationen (valfritt)
Se JavaScript API-dokumentationen för mer information om hur du beviljar medgivanden i programmets hemklientorganisation med hjälp av följande URL (infoga ditt klient-ID och klient-ID):
https://login.microsoftonline.com/{tenantId}/adminconsent?client_id={clientId}
Så här arbetar du med token
Klientdelen bör be om en token workloadClient.auth.acquireAccessToken({});. Du kan använda den här token för att autentisera med serverdelen.
Om du vill komma åt en resurs skickar du din token till serverdelen och försöker byta ut den med hjälp av ett OBO-flöde för resursen. Du kan också använda token som tagits emot från kontroll-API:er (CRUD/Jobb) och försöka byta ut den mot den resursen.
Om utbytet misslyckas av medgivandeskäl meddelar du klientdelen och anropar workloadClient.auth.acquireAccessToken({additionalScopesToConsent:[resource]}); och försöker igen.
Om utbytet misslyckas av MFA-skäl meddelar du klientdelen tillsammans med anspråket som togs emot när du försökte byta ut och anropa workloadClient.auth.acquireAccessToken({claimsForConditionalAccessPolicy:claims});.
Exempel finns i: Exempel på felsvar.
Mer information om felspridning från arbetsbelastningsserverdelen till arbetsbelastningsklientdelen finns i Kommunikationsguide för arbetsbelastning.
Kommentar
Den token som du får när du hämtar en token i klientdelen är inte relaterad till additionalScopesToConsent som du skickar. Det innebär att när användaren har samtyckt kan du använda valfri token som du har fått från workloadClient.auth.acquireAccessToken för ditt OBO-flöde.