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
ouGroupSID
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.
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.
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.
Lorsque vous sélectionnez Groupes affectés à l’application, un groupe est inclus dans la groups
revendication si les conditions suivantes sont remplies :
- le groupe est affecté à l’application Entreprise
- l’utilisateur est un membre direct du groupe.
À 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.
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
- 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 Microsoft Entra ID montre comment Microsoft Entra ID peut fournir les informations d’appartenance de groupe d’un utilisateur dans des jetons à utiliser dans les applications.
- Les meilleures pratiques de sécurité pour les propriétés d’application décrivent 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.
- Les étendues de la plateforme d’identités Microsoft, les autorisations et le consentement explique les concepts fondamentaux de l’accès et de l’autorisation pour vous aider à créer des applications plus sécurisées et fiables.
- Utilisez les meilleures pratiques de développement de la gestion des identités et des accès Confiance Zéro dans votre cycle de développement d'applications pour créer des applications sécurisées.