Freigeben über

Back-End-Authentifizierung und Autorisierung – Übersicht

  • Artikel

Bei der Beispielworkload für Fabric-Entwickler gibt es die folgenden Authentifizierungsflüsse auf der Back-End-Seite.

Authentifizierung und Autorisierung von Anforderungen von Fabric an die Workload

Struktur des Autorisierungsheaders

Der Autorisierungsheader hat ein bestimmtes Tokenformat:

SubjectAndAppToken1.0 subjectToken="delegated token", appToken="S2S token"

Dieses Format umfasst zwei unterschiedliche Token:

  • subjectToken: Ein delegiertes Token, das den Benutzer repräsentiert, in dessen Auftrag der Vorgang ausgeführt wird.
  • appToken: Ein spezifisches Token für die Fabric-Anwendung.

Für den Einsatz eines Headers mit zwei Token gibt es dreierlei Gründe:

  • Validierung: Die Workload kann durch Validierung des appToken überprüfen, ob die Anforderung von Fabric stammt.

  • Benutzerkontext: Das subjectToken liefert einen Benutzerkontext für die ausgeführte Aktion.

  • Kommunikation zwischen Diensten: Die Workload kann über das subjectToken ein On-Behalf-Of-Token (OBO) abrufen und ist dann in der Lage, mit einem Benutzertoken andere Dienste aufzurufen.

Authentifizierung

Die wichtigsten Authentifizierungsprüfungen für SubjectAndAppToken sind:

  • Die Überprüfung und Analyse des Werts des Autorisierungsheaders erfolgt in der Methode AuthenticateControlPlaneCall. Das Token muss mit dem Präfix „SubjectAndAppToken1.0“ beginnen und zwei Token enthalten – subjectToken und appToken.

  • Validierung der Entra-Tokeneigenschaften: Sowohl subjectToken als auch appToken werden in der Methode ValidateAadTokenCommon auf gängige Microsoft Entra-Tokeneigenschaften überprüft. Zu diesen Eigenschaften gehören Tokensignatur, Tokenlebensdauer, Tokenzielgruppe (Workload-App-Zielgruppe) und Tokenversion (1.0) und Aussteller.

  • Validierung der appToken-Eigenschaften: Das appToken sollte keinen scp-Anspruch haben, sondern einen idtyp-Anspruch mit App als Wert. Wir überprüfen zudem diesen tid-Anspruch in der Mandanten-ID des Workloadherausgebers.

    Beispiele für appToken-Ansprüche:

    {
"aud": "api://localdevinstance/00001111-aaaa-2222-bbbb-3333cccc4444/Fabric.WorkloadSample/123",
"iss": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
"iat": 1700047232,
"nbf": 1700047232,
"exp": 1700133932,
"aio": "E2VgYLjBuv2l+c6cmm/iP/bnL2v+AQA=",
"appid": "11112222-bbbb-3333-cccc-4444dddd5555"
"appidacr": "2",
"idp": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
"idtyp": "app",
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"rh": "0.ACgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZAAA.",
"sub": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff",
"uti": "5bgMXs3uMUSAHCruRjACAA",
"ver": "1.0"
}

  • Validierung der subjectToken-Eigenschaften: Stellen Sie sicher, dass das subjectToken einen scp-Anspruch mit dem Bereich FabricWorkloadControl enthält, dass es im Token keinen idtyp-Anspruch gibt und dass appid gleich ist wie im appToken.

    Beispiele für subjectToken-Ansprüche:

    {
"aud": "api://localdevinstance/00001111-aaaa-2222-bbbb-3333cccc4444/Fabric.WorkloadSample/123",
"iss": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
"iat": 1700050446,
"nbf": 1700050446,
"exp": 1700054558,
"acr": "1",
"aio": "ATQAy/8VAAAAUgWRMRnBo4VGHvrKRykUXOXBNKS1cHnBxLrYkZJJGSjAVyJGBecbLdSud1GUakER",
"amr": [
    "pwd"
],
"appid": "11112222-bbbb-3333-cccc-4444dddd5555"
"appidacr": "2",
"ipaddr": "46.117.19.50",
"name": "john doe",
"oid": "bbbbbbbb-1111-2222-3333-cccccccccccc",
"rh": "0.ASgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZANQ.",
"scp": "FabricWorkloadControl",
"sub": "X0Wl85UA-uOmdkQz5MoT-hEgYZXDq9FYdS8g2bFUaZA",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff",
"unique_name": "user1@constso.com",
"upn": "user1@constso.com",
"uti": "_llZwmJoSUiHv-kw6tfDAA",
"ver": "1.0"
}

Siehe IAuthenticationService.

Hinweis

Alle Validierungen in unserem Beispielcode gelten für Token der Version 1.0.

Autorisierung

Sobald bestätigt ist, dass die Anforderung vom Fabric-Dienst stammt (über das appToken), hat Fabric basierend auf den Berechtigungsmetadaten überprüft, dass der Benutzer über die erforderlichen Berechtigungen zum Ausführen der Aktion verfügt.

Authentifizierung und Autorisierung von Anforderungen von der Workload an Fabric

Anforderungen zur Workloadsteuerung

APIs zur Workloadsteuerung sind spezielle Fabric-APIs, die Workloads mit der Lebenszyklusverwaltung für Fabric-Elemente unterstützen. Diese APIs verwenden das gleiche Autorisierungsheaderformat SubjectAndAppToken1.0.

SubjectAndAppToken1.0 subjectToken="delegated token", appToken="S2S token"

Aufrufe, die vom Workload stammen, einschließlich folgender Token:

  • subjectToken: Ein benutzerdelegiertes Token (abgerufen über den OBO-Fluss), das den Benutzer repräsentiert, in dessen Auftrag der Vorgang ausgeführt wird. Fabric bestätigt, ob der Benutzer über die erforderlichen Berechtigungen zur Ausführung der nötigen Aktion verfügt.

  • appToken: Ein spezifisches Token für die Workloadanwendung. Fabric überprüft, ob dieses Token von der Microsoft Entra-App des Workload stammt, zu dem das betreffende Fabric-Element gehört und der sich auf dem Mandanten des Workloadherausgebers befindet.

Siehe Methode ValidatePermissions in AuthorizationHandler.

Öffentliche APIs

Zum Aufrufen öffentlicher Fabric-APIs sollte der Workload ein standardmäßiges Microsoft Entra-OBO-Token mit den entsprechenden API-Bereichen abrufen und als Bearertoken im Autorisierungsheader der Anforderung übergeben.

Siehe FabricExtensionController.

Authentifizierung und Autorisierung von Anforderungen vom Workload-FE an das Workload-BE

Authorization header (Autorisierungsheader)

Der Autorisierungsheader in einer vom Workload-FE an das Workload-BE gesendeten Anforderung verwendet ein Standard-Bearertoken.

Authentifizierung

Die Methode AuthenticateControlPlaneCall im Workload-BE ist für die Validierung des Tokens zuständig. Es werden in erster Linie die folgenden Prüfungen vorgenommen:

  • Tokenlebensdauer: Stellt sicher, dass das Token innerhalb des gültigen Nutzungszeitraums liegt.

  • Signatur: Überprüft die Echtheit des Tokens.

  • Zielgruppe: Überprüft, ob die Zielgruppe des Tokens mit der Microsoft Entra-App des Workload übereinstimmt.

  • Aussteller: Validiert den Aussteller des Tokens.

  • Zulässige Bereiche: Validiert die Bereiche, zu deren Zugriff das Token berechtigt ist.

Die Autorisierung erfolgt durch Aufrufen der Methode ValidatePermissions. Diese Methode ruft die API resolvePermissions im Fabric-Workloadsteuerungsendpunkt für das betreffende Fabric-Element auf und überprüft, ob der Benutzer über die erforderlichen Berechtigungen für den Vorgang verfügt.

Zeitintensive Vorgänge - Aktualisierungstoken

Die Autorisierung erfolgt durch Aufrufen der Methode ValidatePermissions. Diese Methode ruft die API resolvePermissions im Fabric-Workloadsteuerungsendpunkt für das betreffende Fabric-Element auf und überprüft, ob der Benutzer über die erforderlichen Berechtigungen für den Vorgang verfügt.

Wenn Ihre Workloads beispielsweise zeitintensive Vorgänge umfassen, die Teil von JobScheduler sind, kann es vorkommen, dass die Lebensdauer des Token nicht ausreicht. Weitere Informationen zur Authentifizierung zeitintensiver Prozesse finden Sie unter Zeitintensive OBO-Prozesse.