Partager via

Vue d’ensemble de l’authentification et l’autorisation du back-end

  • Article

L’exemple de charge de travail du développeur Fabric comporte les flux d’authentification suivants côté back-end.

Authentification et autorisation des requêtes de Fabric vers la charge de travail

Structure d’en-tête d’autorisation

L’en-tête d’autorisation utilise un format de jeton spécifique :

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

Ce format comprend deux jetons distincts :

  • subjectToken : jeton délégué représentant l’utilisateur au nom duquel l’opération est en cours d’exécution.
  • appToken : jeton spécifique à l’application Fabric.

La raison d’être de l’utilisation d’un en-tête double jeton est triple :

  • Validation : la charge de travail peut vérifier que la requête provient de Fabric en validant le appToken.

  • Contexte utilisateur : le subjectToken fournit un contexte utilisateur pour l’action en cours d’exécution.

  • Communication inter-service : la charge de travail peut acquérir un jeton OBO (On-Behalf-Of) à l’aide du subjectToken, ce qui lui permet d’appeler d’autres services avec un jeton utilisateur.

Authentification

Les vérifications d’authentification principales effectuées pour SubjectAndAppToken sont les suivantes :

  • La validation et l’analyse de la valeur d’en-tête d’autorisation s’effectuent dans la méthode AuthenticateControlPlaneCall. Le jeton doit commencer par le préfixe « SubjectAndAppToken1.0 » et inclure deux jetons - subjectToken et appToken.

  • Validation des propriétés de jeton Entra : à la fois subjectToken et appToken sont validées pour les propriétés de jeton AAD courantes dans la méthode ValidateAadTokenCommon. Ces propriétés incluent la signature de jeton, la durée de vie des jetons, l’audience des jetons (audience de l’application de charge de travail) et la version du jeton (1.0) et l’émetteur.

  • validation des propriétés appToken : la appToken ne doit pas avoir de revendication scp, mais doit avoir une revendication idtyp avec l’application comme valeur. Nous vérifions également cette revendication tid dans l’ID de client de l’éditeur de charge de travail.

    Exemples de revendications appToken :

    {
"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"
}

  • Validation des propriétés subjectToken : vérifiez que le subjectToken inclut une revendication scp avec l’étendue FabricWorkloadControl, qu’il n’existe aucune revendication idtyp présente dans le jeton et qu’elle a la même appid que dans le appToken.

    Exemples de revendications subjectToken :

    {
"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"
}

Voir IAuthenticationService.

Remarque

Toutes les validations de notre exemple de code sont destinées aux jetons version 1.0.

Autorisation

Une fois qu’il a été confirmé que la demande provient du service Fabric (via le appToken), Fabric a vérifié que l’utilisateur dispose des autorisations nécessaires pour effectuer l’action, en fonction des métadonnées d’autorisations de Fabric.

Authentification et autorisation des demandes de la charge de travail vers Fabric

Demandes de contrôle de charge de travail

Les API de contrôle de la charge de travail sont des API Fabric spéciales qui prennent en charge les charges de travail avec leur gestion du cycle de vie des éléments Fabric. Ces API utilisent le même format d’en-tête d’autorisation SubjectAndAppToken1.0.

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

Les appels provenant de la charge de travail incluent les jetons suivants :

  • subjectToken : jeton délégué par l’utilisateur (obtenu via le flux OBO) représentant l’utilisateur pour lequel l’opération est en cours d’exécution. Fabric vérifiera que l’utilisateur dispose des autorisations requises pour effectuer l’action requise.

  • appToken : jeton spécifique à l’application de charge de travail. Fabric vérifie que ce jeton provient de l’application Microsoft Entra de la charge de travail à laquelle appartient l’élément Fabric approprié et qui se trouve sur le client de l’éditeur de charge de travail.

Consultez la méthode ValidatePermissions dans AuthorizationHandler.

API publiques

Pour appeler des API Fabric publiques, la charge de travail doit acquérir un jeton OBO Entra ID standard avec les étendues d’API appropriées et le transmettre en tant que jeton du porteur dans l’en-tête d’autorisation de la demande.

Consultez FabricExtensionController.

Authentification et autorisation des requêtes de la charge de travail du FE vers la charge de travail du BE

En-tête d’autorisation.

L’en-tête d’autorisation d’une demande envoyée de la charge de travail FE à la charge de travail BE utilise un jeton du porteur standard.

Authentification

La méthode AuthenticateControlPlaneCall dans la charge de travail BE est chargée de valider le jeton. Les vérifications principales effectuées sont les suivantes :

  • Durée de vie du jeton : garantit que le jeton est dans sa période d’utilisation valide.

  • Signature : vérifie l’authenticité du jeton.

  • Public : vérifie que le public du jeton correspond à l’application Microsoft Entra de la charge de travail.

  • Émetteur: Valide l’émetteur du jeton.

  • Étendues autorisées : valide les étendues auxquelles le jeton est autorisé à accéder.

L’autorisation est obtenue en invoquant la méthode ValidatePermissions. Cette méthode appelle l’API resolvePermissions dans le point de terminaison de contrôle de charge de travail Fabric pour l’élément Fabric approprié et vérifie que l’utilisateur dispose des autorisations nécessaires pour l’opération.

Opérations de longue durée – Jeton d’actualisation

L’autorisation est obtenue en invoquant la méthode ValidatePermissions. Cette méthode appelle l’API resolvePermissions dans le point de terminaison de contrôle de charge de travail Fabric pour l’élément Fabric approprié et vérifie que l’utilisateur dispose des autorisations nécessaires pour l’opération.

Si vos charges de travail incluent des opérations durables, par exemple, dans le cadre de JobScheduler vous risquez de vous trouver dans une situation où la durée de vie du jeton n’est pas suffisante. Pour plus d’informations sur l’authentification du processus durable, consultez Processus OBO durables.