Javascript-API für die Authentifizierung

Das Fabric-Front-End bietet eine Javascript-API für Fabric-Workloads zum Abrufen eines Tokens für ihre Anwendung in Microsoft Entra ID. In diesem Artikel wird diese API beschrieben.

API

acquireAccessToken(params: AcquireAccessTokenParams): Promise<AccessToken>;  
export interface AcquireAccessTokenParams {
    additionalScopesToConsent?: string[];  
    claimsForConditionalAccessPolicy?: string;
    promptFullConsent?: boolean;
}

Die API gibt ein AccessToken-Objekt zurück, das das Token selbst und ein Ablaufdatum für das Token enthält.

Um die API im Frontend-Beispiel aufzurufen, erstellen Sie einen Musterartikel, scrollen Sie dann nach unten, und wählen Sie Navigieren zur Authentifizierungsseite. Von dort aus können Sie Zugriffstoken abrufen auswählen, um ein Token zurückzubekommen.

Zustimmungen

Um zu verstehen, warum Zustimmungen erforderlich sind, gehen Sie bitte zu Zustimmung des Benutzers und Administrators in Microsoft Entra-ID .

Wie funktionieren Zustimmungen in Fabric-Workloads?

Um eine Zustimmung für eine bestimmte Anwendung zu erteilen, erstellt Fabric FE eine MSAL-Instance, die mit der Anwendungs-ID des Workloads konfiguriert ist, und fordert ein Token für die bereitgestellten Bereiche an (additionalScopesToConsent – siehe AcquireAccessTokenParams).

Wenn Sie nach einem Token mit der Workload-Anwendung für einen bestimmten Bereich fragen, zeigt die Microsoft Entra-ID ein Popup Zustimmung an, falls sie fehlt, und leitet dann das Popupfenster an in der Anwendung konfigurierten Umleitungs-URI um.

Normalerweise befindet sich der Umleitungs-URI in derselben Domäne wie die Seite, die das Token angefordert hat, damit die Seite auf das Popup zugreifen und es schließen kann.

In unserem Fall ist es nicht in der gleichen Domäne da Fabric das Token anfordert und der Umleitungs-URI des Workloads nicht in der Fabric-Domäne ist. Wenn das Zustimmungsdialogfeld geöffnet wird, muss es also nach der Umleitung manuell geschlossen werden. Wir verwenden den im Umleitungs-URI zurückgegebenen Code nicht, daher schließen wir ihn einfach automatisch (wenn Microsoft Entra ID das Popup an den Umleitungs-URI umleitet, wird er einfach geschlossen).

Sie können den Code/die Konfiguration des Umleitungs-URI in der Datei index.ts sehen.

Hier sehen Sie ein Beispiel für ein Zustimmungs-Popup für unsere App „Meine Workload-App“ und deren Abhängigkeiten (Speicher und Power BI), die wir bei Authentifizierung-Setup konfiguriert haben:

Eine weitere Möglichkeit zum Erteilen von Zustimmungen im Start-Mandanten (optional)

Um eine Zustimmung im Startmandanten der Anwendung zu erhalten, können Sie Ihren Mandantenadministrator bitten, eine Zustimmung für den gesamten Mandanten zu erteilen, indem Sie eine URL in folgendem Format verwenden (fügen Sie Ihre eigene Mandanten-ID und die Client-ID ein):

https://login.microsoftonline.com/{tenantId}/adminconsent?client_id={clientId}

AcquireAccessTokenParams

Beim Aufrufen der JS-API „acquireAccessToken“ können wir drei Parameter bereitstellen:

• additionalScopesToConsent: Andere Bereiche, für die eine Zustimmung angefordert werden soll, z. B. Szenarien für die erneute Zustimmung.
• claimsForConditionalAccessPolicy: Ansprüche, die von Microsoft Entra ID zurückgesendet werden, wenn OBO-Flüsse fehlschlagen, z. B. OBO erfordert die Multi-Factor Authentifizierung.
• promptFullConsent: Fordert ein vollständiges Zustimmungsfenster der statischen Abhängigkeiten der Anwendung der Workloads an.

additionalScopesToConsent

Wenn das Workload-Front-End nach einem Token fragt, das für Aufrufe an das Workload-Back-End verwendet werden soll, sollte dieser Parameter NULL sein. Das Workload-Back-End kann OBO für das empfangene Token aufgrund eines Fehlers „fehlende Zustimmung“ nicht ausführen. In diesem Fall muss das Workload-Back-End den Fehler an das Workload-Front-End weitergeben und diesen Parameter bereitstellen.

claimsForConditionalAccessPolicy

Dieser Parameter wird verwendet, wenn OBO-Fehler im Workload BE auftreten, durch einige Richtlinien für bedingten Zugriff, die für den Mandanten konfiguriert wurden.

OBO-Fehler aufgrund bedingter Zugriffsrichtlinien geben eine Zeichenkette namens „claims“ zurück.Diese Zeichenkette sollte an die Workload-FE gesendet werden, an der das FE ein Token anfordern und den Anspruch als claimsForConditionalAccessPolicy übergeben soll. Weitere Informationen finden Sie unter Behandeln der mehrstufigen Authentifizierung (MFA), des bedingten Zugriffs und der inkrementellen Zustimmung.

Weitere Informationen finden Sie unter AuthenticationService AddBearerClaimToResponse-Verwendung im BE-Beispiel, um Beispiele für Antworten anzuzeigen, wenn OBO-Vorgänge aufgrund fehlender Zustimmung oder Richtlinien für bedingten Zugriff fehlschlagen.

Weitere Informationen zu diesen additionalScopesToConsent und claimsForConditionalAccessPolicy und Beispiele für die Verwendung finden Sie unter Workload-Authentifizierungsrichtlinien und Deep Dive.

promptFullConsent

Wenn dies als WAHR übergeben wird, wird eine vollständige Zustimmung der statischen Abhängigkeiten für den Benutzer angezeigt, unabhängig davon, ob zuvor eine Zustimmung erteilt wurde oder nicht. Eine Beispielverwendung für diesen Parameter ist das Hinzufügen einer Schaltfläche zur Benutzeroberfläche, auf welcher der Benutzer sie verwenden kann, um der Workload vollständige Zustimmung zu erteilen.