Partager via


Configurer des revendications de groupe et des rôles d'application dans les jetons

Cet article vous aide à configurer vos applications avec des définitions de rôles d’application et à affecter des groupes de sécurité aux rôles d’application afin d’améliorer la flexibilité et le contrôle tout en augmentant la sécurité des applications avec des privilèges minimum.

Microsoft Entra ID prend en charge l’envoi de groupes de sécurité affectés par un utilisateur, des rôles d’annuaire Microsoft Entra et des groupes de distribution en tant que revendications dans un jeton. Vous pouvez utiliser cette approche pour piloter l’autorisation dans les applications. Toutefois, Microsoft Entra ID limite la prise en charge des groupes dans un jeton selon la taille du jeton. Lorsque l’utilisateur est membre d’un trop grand nombre de groupes, aucun groupe n’est présent dans le jeton.

Dans cet article, vous découvrez une autre approche pour obtenir des informations utilisateur dans des jetons à l’aide de la prise en charge des groupes dans Microsoft Entra. Au lieu de cela, vous configurez vos applications avec des définitions de rôles d’application et affectez des groupes aux rôles d’application. Cette meilleure pratique de développement confiance zéro permet d’améliorer la flexibilité et le contrôle tout en augmentant la sécurité de l’application avec des privilèges minimum.

Vous pouvez configurer des revendications de groupe dans des jetons que vous pouvez utiliser dans vos applications pour l’autorisation. N’oubliez pas que les informations de groupe dans le jeton sont actuelles uniquement lorsque vous recevez le jeton. Les revendications de groupe prennent en charge deux modèles principaux :

  • Groupes identifiés par leur attribut d’identificateur d'objet (OID) Microsoft Entra.
  • Groupes identifiés par l’attribut sAMAccountName ou GroupSID pour les groupes et utilisateurs synchronisés par Active Directory.

L’appartenance au groupe peut prendre des décisions d’autorisation. Par exemple, l’exemple suivant montre certaines revendications dans un jeton. Vous pouvez ajouter des revendications de groupe et des rôles à des jetons d’id ou d’accès.

"aud": "e18c04b1-4868-4b93-93d1-8d71f17ab99b", 
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0", 
"iat": 1669657224, "nbf": 1669657224, "exp": 1669661124, 
"groups": [ 
   "0760b6cf-170e-4a14-91b3-4b78e0739963", 
   "3b2b0c93-acd8-4208-8eba-7a48db1cd4c0" 
 ],
"oid": "cb7eda1b-d09a-40ae-b8bb-37836ebc6abd",
"sub": "3OBtLXUC2ZrN_ADLNjW9X4o0lcd61py7lgHw3Skh77s",
"tid": "833ced3d-cb2e-41ce-92f1-29e2af035ddc", 
"ver": "2.0", 
"wids": [ 
   "cf1c38e5-3621-4004-a7cb-879624dced7c", 
   "b79fbf4d-3ef9-4689-8143-76b194e85509" 
 ]

Le groups tableau de revendications comprend les ID des groupes auxquels cet utilisateur est membre. Le wids tableau comprend les ID des rôles Microsoft Entra attribués à cet utilisateur. Ici, cf1c38e5-3621-4004-a7cb-879624dced7c indique que les rôles attribués à cet utilisateur incluent le développeur d’applications et le membre standard, comme 3b2b0c93-acd8-4208-8eba-7a48db1cd4c0 indiqué.

Votre application peut prendre des décisions d’autorisation en fonction de la présence ou de l’absence de ces revendications et de leurs valeurs. Consultez les rôles intégrés Microsoft Entra pour obtenir la liste des valeurs de la wids revendication.

Pour ajouter les revendications groups et les revendications wids à vos jetons, sélectionnez Tous les groupes, comme indiqué dans l'exemple suivant de l'écran Enregistrements d'applications | Configuration des jetons | Revendications optionnelles | Modifier les groupes et les revendications.

Capture d'écran de l'écran Modifier les demandes de groupes montre les types de groupes sélectionnés : Groupes attribués à l'application.

Dépassements de groupe

Lorsque vous demandez tous les groupes dans votre jeton, comme indiqué dans l’exemple ci-dessus, vous ne pouvez pas vous appuyer sur le jeton ayant la groups revendication dans votre jeton. Il existe des limites de taille sur les jetons et sur groups les revendications afin qu’elles ne deviennent pas trop volumineuses. Lorsque l’utilisateur est membre d’un trop grand nombre de groupes, votre application doit obtenir l’appartenance au groupe de l’utilisateur auprès de Microsoft Graph. Les limites des groupes dans une groups revendication sont les suivantes :

  • 200 groupes pour les jetons web JSON (JWT).
  • 150 groupes pour les jetons SAML (Security Assertion Markup Language).
  • Six groupes lors de l’utilisation du flux implicite (par exemple, en utilisant ASP.NET cœur qui obtient des jetons d’ID via la partie de flux implicite d’un flux hybride).
    • Le flux implicite n’est plus recommandé pour les applications web monopage.
    • Le flux implicite peut être utilisé dans les applications web pour le jeton d’ID uniquement, jamais le jeton d’accès, dans un flux hybride OAuth2.

Si vous utilisez OpenID Connect ou OAuth2, vous pouvez avoir jusqu’à 200 groupes dans votre jeton. Si vous utilisez SAML, vous ne pouvez avoir que 150 groupes, car les jetons SAML sont plus volumineux que les jetons OAuth2 et OpenID Connect. Si vous utilisez le flux implicite, la limite est de six, car ces réponses s’affichent dans l’URL. Dans tous ces cas, au lieu d’avoir une revendication groups, vous voyez une indication (appelée dépassement de groupe) qui vous indique que l’utilisateur est membre d’un trop grand nombre de groupes pour passer dans votre jeton.

Dans l’exemple de jeton suivant, pour une connexion OpenID ou OAuth2, un jeton web JSON (JWT), il n’existe pas de revendication groups si l’utilisateur est membre d’un trop grand nombre de groupes. Au lieu de cela, il existe une revendication _claim_names qui contient un membre groups du tableau.

Capture d’écran de l’exemple de jeton montrant la requête.

Dans l’exemple de jeton ci-dessus, vous voyez que la groups revendication est censée être mappée à src1. En théorie, vous recherchez ensuite la _claim_sources revendication, puis trouvez le src1 membre. À partir de là, vous trouverez la requête Graph que vous utiliseriez pour obtenir l’appartenance au groupe. Toutefois, il existe un problème avec ce que vous voyez dans l’exemple de requête Graph. Il accède à Azure AD Graph (que Microsoft déprécie), donc ne l’utilisez pas.

L’indication de dépassement de flux implicite est effectuée avec une hasgroups revendication au lieu de la groups revendication.

Pour garantir une autorisation appropriée à l’aide de l’appartenance au groupe, avez votre application case activée pour la revendication groups. Si elle est présente, utilisez cette revendication pour déterminer l’appartenance au groupe de l’utilisateur. S’il n’existe aucune revendication groups, case activée pour l’existence d’une revendication hasgroups ou d’une revendication _claim_names avec un groups membre du tableau. Si l’une de ces revendications est présente, l’utilisateur est membre d’un trop grand nombre de groupes pour le jeton. Dans ce cas, votre application doit utiliser Microsoft Graph pour déterminer l’appartenance au groupe pour l’utilisateur. Consultez Lister les appartenances d’un utilisateur (directes et transitives) pour rechercher tous les groupes, à la fois directs et transitifs, dont l’utilisateur est membre.

Si votre application nécessite des informations d’appartenance à un groupe en temps réel, utiliser Microsoft Graph pour déterminer l’appartenance au groupe. N’oubliez pas que les informations contenues dans le jeton que vous recevez sont à jour uniquement au moment de l’acquisition du jeton.

Consultez l’exemple suivant de l’écran Enregistrements d'applications | Configuration des jetons | Revendications optionnelles | Modifier les groupes et les revendications. L’une des façons d’éviter d’atteindre une revendication de dépassement de groupe consiste à sélectionner les groupes affectés à l’application sur l’écran Modifier la revendication des groupes au lieu de tous les groupes.

Capture d'écran de l'écran Modifier les requêtes de groupes montre les types de groupes sélectionnés : Groupes de sécurité, Rôles de répertoire et Tous les groupes.

Lorsque vous sélectionnez Groupes affectés à l’application, un groupe est inclus dans la groups revendication si les conditions suivantes sont remplies :

À compter de la publication de cet article, les groupes affectés à l’option d’application ne prennent pas en charge l’appartenance indirecte. L’attribution de groupe nécessite au moins une licence de niveau P1. Un client gratuit ne peut pas affecter de groupes à une application.

Groupes et rôles d'application

Une autre façon d’éviter le problème de dépassement de groupe consiste à permettre à l’application de définir des rôles d’application qui autorisent les utilisateurs et les groupes en tant que types de membres. Comme le montre l'exemple suivant de l'écran Enregistrements d'applications | Rôles d'application | Créer un rôle d'application, sélectionner Utilisateurs/Groupes pour les types de membres autorisés.

La capture d'écran de l'écran Créer un rôle d'application montre les types de membres autorisés : Utilisateurs/Groupes.

Après avoir créé le rôle d’application dans l’inscription de l’application, les professionnels de l’informatique peuvent attribuer des utilisateurs et des groupes au rôle. Votre application obtient une revendication roles dans votre jeton (jeton d’ID pour l’application, jeton d’accès pour les API) avec tous les rôles attribués à l’utilisateur connecté, comme indiqué dans l’exemple de jeton suivant.

"aud": "acaf6ce9-81f0-462a-a93d-a314070738d3",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0",
"iat": 1670826509, "nbf": 1670826509, "exp": 1670830409,
"name": "Kyle Marsh",
"oid": "cb7eda1b-d09a-419e-b8bb-37836ebc6abd",
"preferred_username": "kylemar@idfordevs.dev",
"roles": [
 "Approver",
 "Reviewer" 
],
"sub": "dx-4lf-0loB3c3uVrULnZ2VTLuRRWYff0q7-QlIfYU4",
"tid": "833ced3d-cb3e-41de-92f1-29e2af035ddc",

N’oubliez pas que votre application gère les conditions suivantes :

  • absence de roles revendication
  • l’utilisateur n’a aucune attribution de rôle
  • plusieurs valeurs dans la revendication roles lorsque l’utilisateur a plusieurs attributions de rôle

Quand vous créez des rôles d’application qui autorisent l’utilisateur et les groupes en tant que membres, définissez toujours un rôle d’utilisateur de référence sans rôle d’autorisation élevé. Quand une configuration d’application Entreprise nécessite une affectation, seuls les utilisateurs disposant d’une affectation directe à une application ou appartenant à un groupe affecté à l’application peuvent utiliser l’application.

Si votre application dispose de rôles d’application définis qui autorisent les utilisateurs et les groupes en tant que membres, quand un utilisateur ou un groupe est attribué à l’application, l’un des rôles d’application définis doit faire partie de l’affectation des utilisateurs ou du groupe à l’application. Si votre application dispose uniquement de rôles élevés (comme admin) pour l’application, le rôle d’administrateur est attribué à tous les utilisateurs et groupes. Lorsque vous définissez un rôle de base (tel que user), les utilisateurs et les groupes affectés à l'application peuvent se voir attribuer le rôle d'utilisateur de base.

Les rôles permettent non seulement d’éviter les revendications de dépassement de groupe, mais ils présentent également l’avantage qu’il n’est pas nécessaire de mapper un ID de groupe ou un nom à sa signification dans votre application. Par exemple, votre code peut rechercher la revendication du rôle d'administrateur au lieu de parcourir les groupes dans les revendications groups et de décider quels ID de groupe doivent être autorisés à utiliser la fonctionnalité d'administration.

Vérifier et utiliser des rôles dans votre code

Lorsque vous définissez des rôles d'application pour votre application, il est de votre responsabilité d'implémenter une logique d'autorisation pour ces rôles. Consultez Implémenter le contrôle d’accès en fonction du rôle dans les applications pour savoir comment implémenter la logique d’autorisation dans vos applications.

Étapes suivantes