Partager via

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

  • Article

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 des groupes de sécurité, des rôles de répertoire Microsoft Entra et des groupes de distribution attribués à un utilisateur en tant que revendications dans un jeton. Vous pouvez utiliser cette approche pour piloter l’autorisation dans les applications. Cependant, Microsoft Entra ID limite la prise en charge des groupes dans un jeton en fonction de la taille de celui-ci. 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 allez apprendre une autre approche pour obtenir des informations utilisateur dans des jetons à l’aide du support de groupe 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 bonne pratique Zero Trust pour les développeurs améliore la flexibilité et le contrôle tout en augmentant la sécurité des applications grâce au principe du moindre privilège.

Vous pouvez configurer les revendications de groupes dans les 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 OID (Microsoft Entra Object Identifier).
  • Groupes identifiés par l’attribut sAMAccountName ou GroupSID pour les groupes et utilisateurs synchronisés avec Active Directory.

L'appartenance à un groupe peut influencer les 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": "00001111-aaaa-2222-bbbb-3333cccc4444", 
"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": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"sub": "3OBtLXUC2ZrN_ADLNjW9X4o0lcd61py7lgHw3Skh77s",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff", 
"ver": "2.0", 
"wids": [ 
   "cf1c38e5-3621-4004-a7cb-879624dced7c", 
   "b79fbf4d-3ef9-4689-8143-76b194e85509" 
 ]

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

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. Veuillez consulter la section Rôles intégrés Microsoft Entra pour une liste des valeurs de la revendication wids.

Pour ajouter les revendications groups et wids à vos jetons, sélectionnez Tous les groupes, comme illustré dans l’exemple suivant de l’écran Enregistrements d’applications | Configuration du jeton | Revendications facultatives | Modifier la revendication des groupes.

La capture d’écran de l’écran Modifier les revendications des groupes montre les types de groupes sélectionnés : Groupes attribués à l’application.

Surplus de groupes

Lorsque vous demandez tous les groupes dans votre jeton, comme montré dans l’exemple ci-dessus, vous ne pouvez pas compter sur la présence de la revendication groups dans votre jeton. Il existe des limites de taille sur les jetons et sur les revendications groups 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 revendication groups 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 Core qui obtient des jetons d'identité via la partie 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 surplus de groupes) qui vous informe que l’utilisateur est membre de trop nombreux groupes pour être inclus dans votre jeton.

La revendication groups est censée être associée à src1. En théorie, vous rechercheriez alors la revendication _claim_sources, puis trouveriez le membre src1. À 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 requête hasgroups au lieu de la requête groups.

Pour garantir une autorisation correcte basée sur l’appartenance à des groupes, votre application doit vérifier 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, vérifiez l’existence d’une revendication hasgroups ou d’une revendication _claim_names avec un membre groups 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 Répertorier les appartenances d’un utilisateur (direct et transitif) 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, utilisez 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.

Veuillez consulter l’exemple suivant de l’écran Enregistrements d’applications | Configuration du jeton | Revendications facultatives | Modifier la revendication des groupes. Une façon d’éviter un surplus de revendications de groupes consiste à sélectionner Groupes attribués à l’application sur l’écran Modifier la revendication des groupes au lieu de Tous les groupes.

Capture d’écran de la fenêtre de modification des revendications de groupe montrant les types de groupes sélectionnés : groupes de sécurité, rôles d’annuaire et tous les groupes.

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

À la date de publication de cet article, les groupes associés à l'option de l'application ne prennent pas en charge l’appartenance indirecte. L’attribution de groupes nécessite au moins une licence de niveau P1. Un tenant gratuit ne peut pas attribuer 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 illustré dans l’exemple suivant de l’écran Enregistrements d’applications | Rôles d’application | Créer un rôle d’application, sélectionnez Utilisateurs/Groupes pour Types de membres autorisés.

Capture d’écran de création d’un rôle d’application montrant les types de membres autorisés : Utilisateurs/groupes.

Ayant créé le rôle d’application dans l’enregistrement de l'application, les professionnels de l’informatique peuvent affecter 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 par l’utilisateur connecté, comme indiqué dans l’exemple de jeton suivant.

"aud": "11112222-bbbb-3333-cccc-4444dddd5555",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0",
"iat": 1670826509, "nbf": 1670826509, "exp": 1670830409,
"name": "Kyle Marsh",
"oid": "bbbbbbbb-1111-2222-3333-cccccccccccc",
"preferred_username": "kylemar@idfordevs.dev",
"roles": [
 "Approver",
 "Reviewer" 
],
"sub": "dx-4lf-0loB3c3uVrULnZ2VTLuRRWYff0q7-QlIfYU4",
"tid": "ccccdddd-2222-eeee-3333-ffff4444aaaa",

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

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

Lorsque 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ôles d’autorisation élevés. Lorsqu’une configuration d’application d’entreprise nécessite une affectation, seuls les utilisateurs ayant une affectation directe à une application ou une appartenance à un groupe affecté à l’application peuvent utiliser l’application.

Si votre application a défini des rôles d’application qui autorisent les utilisateurs et les groupes en tant que membres, lorsqu’un utilisateur ou un groupe est affecté à l’application, l’un des rôles d’application définis doit faire partie de l’affectation de l’utilisateur ou du groupe à l’application. Si votre application n’a défini que des rôles élevés (tels que admin) pour l’application, tous les utilisateurs et groupes reçoivent le rôle d’administrateur. Lorsque vous définissez un rôle de base (par exemple, user), les utilisateurs et les groupes affectés à l’application peuvent être affectés au rôle d’utilisateur de base.

En plus d’éviter les revendications de dépassement concernant les groupes, un autre avantage de l’utilisation des rôles est qu’il n’est pas nécessaire d’établir une correspondance entre un ID de groupe ou un nom et sa signification dans votre application. Par exemple, votre code peut rechercher la prétention de rôle administrateur au lieu de parcourir les groupes dans les revendications groups et décider quels ID de groupe doivent permettre l'accès à 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 vous incombe d’implémenter la 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

  • Personnaliser les jetons décrit les informations que vous pouvez recevoir dans les jetons Microsoft Entra. Il explique comment personnaliser des jetons pour améliorer la flexibilité et le contrôle tout en augmentant la sécurité confiance zéro de l’application avec des privilèges minimum.
  • Configurer les revendications de groupe pour les applications à l’aide de l’ID Microsoft Entra montre comment l’ID Microsoft Entra peut fournir les informations d’appartenance de groupe d’un utilisateur dans des jetons à utiliser dans les applications.
  • meilleures pratiques de sécurité pour les propriétés d’application décrit l’URI de redirection, les jetons d’accès (utilisés pour les flux implicites), les certificats et les secrets, l’URI d’ID d’application et la propriété de l’application.
  • Étendues, autorisations et & consentement de la plateforme d’identité Microsoft expliquent les concepts fondamentaux d’accès et d’autorisation pour vous aider à développer des applications plus sécurisées et fiables.
  • Dans votre cycle de vie de développement d’applications, utilisez les meilleures pratiques de développement de gestion des identités et des accès de Confiance Zéro pour créer des applications sécurisées.