Partager via

Contrôle d’accès en fonction du rôle pour les développeurs d’applications

Le contrôle d’accès en fonction du rôle (RBAC) permet à certains utilisateurs ou groupes d’avoir des autorisations spécifiques pour accéder aux ressources et les gérer. Le RBAC d’application diffère du contrôle d’accès en fonction du rôle Azure et du contrôle d’accès en fonction du rôle Microsoft Entra. Les rôles personnalisés Azure et les rôles intégrés font tous les deux partie d’Azure RBAC, qui est utilisé pour aider à gérer les ressources Azure. Microsoft Entra RBAC est utilisé pour gérer les ressources Microsoft Entra. Cet article explique le RBAC spécifique à l’application. Pour plus d’informations sur l’implémentation d’un RBAC spécifique à l’application, consultez Comment ajouter des rôles d’application à votre application et les recevoir dans le jeton.

Définitions de rôles

RBAC est un mécanisme populaire pour appliquer l’autorisation dans les applications. Lorsqu’une organisation utilise RBAC, un développeur d’applications définit des rôles plutôt que d’autoriser des utilisateurs ou des groupes individuels. Un administrateur peut ensuite attribuer des rôles à différents utilisateurs et groupes pour contrôler qui a accès au contenu et aux fonctionnalités.

RBAC aide un développeur d’applications à gérer les ressources et leur utilisation. RBAC permet également à un développeur d’applications de contrôler les zones d’une application auxquelles les utilisateurs peuvent accéder. Les administrateurs peuvent contrôler quels utilisateurs ont accès à une application à l’aide de la propriété d’affectation d’utilisateur requise . Les développeurs doivent prendre en compte des utilisateurs spécifiques au sein de l’application et ce que les utilisateurs peuvent faire au sein de l’application.

Un développeur d’applications crée d’abord une définition de rôle dans la section d’inscription de l’application dans le Centre d’administration Microsoft Entra. La définition de rôle inclut une valeur retournée pour les utilisateurs affectés à ce rôle. Un développeur peut ensuite utiliser cette valeur pour implémenter la logique d’application pour déterminer ce que ces utilisateurs peuvent ou ne peuvent pas faire dans une application.

Options du RBAC

Les conseils suivants doivent être appliqués lorsque vous envisagez d’inclure l’autorisation de contrôle d’accès en fonction du rôle dans une application :

  • Définissez les rôles requis pour les besoins d’autorisation de l’application.
  • Appliquez, stockez et récupérez les rôles pertinents pour les utilisateurs authentifiés.
  • Déterminez le comportement de l’application en fonction des rôles attribués à l’utilisateur actuel.

Une fois les rôles définis, la plateforme d’identités Microsoft prend en charge plusieurs solutions différentes qui peuvent être utilisées pour appliquer, stocker et récupérer des informations de rôle pour les utilisateurs authentifiés. Ces solutions incluent des rôles d’application, des groupes Microsoft Entra et l’utilisation de magasins de données personnalisés pour les informations de rôle d’utilisateur.

Les développeurs ont la possibilité de fournir leur propre implémentation pour la façon dont les attributions de rôles doivent être interprétées comme des autorisations d’application. Cette interprétation des autorisations peut impliquer l’utilisation d’intergiciels ou d’autres options fournies par la plateforme des applications ou des bibliothèques associées. Les applications reçoivent généralement des informations de rôle d’utilisateur en tant que revendications, puis décident des autorisations utilisateur en fonction de ces revendications.

Rôles d'application

Microsoft Entra ID vous permet de définir des rôles d’application pour votre application et d’affecter ces rôles aux utilisateurs et à d’autres applications. Les rôles que vous attribuez à un utilisateur ou une application définissent leur niveau d’accès aux ressources et aux opérations de votre application.

Lorsque Microsoft Entra ID émet un jeton d’accès pour un utilisateur ou une application authentifié, il inclut les noms des rôles que vous avez attribués à l’entité (l’utilisateur ou l’application) dans la revendication du roles jeton d’accès. Une application comme une API web qui reçoit ce jeton d’accès dans une demande peut ensuite prendre des décisions d’autorisation en fonction des valeurs de la roles revendication.

Groupes

Les développeurs peuvent également utiliser des groupes Microsoft Entra pour implémenter RBAC dans leurs applications, où les appartenances de l’utilisateur dans des groupes spécifiques sont interprétées comme leurs appartenances aux rôles. Lorsqu’une organisation utilise des groupes, le jeton inclut une revendication de groupe. La revendication de groupe spécifie les identificateurs de tous les groupes attribués à l’utilisateur au sein du locataire.

Importante

Lorsque vous travaillez avec des groupes, les développeurs doivent être conscients du concept d’une revendication de dépassement. Par défaut, si un utilisateur est membre de plus que la limite de dépassement (150 pour les jetons SAML, 200 pour les jetons JWT, 6 si vous utilisez le flux implicite), l’ID Microsoft Entra n’émet pas de revendication de groupe dans le jeton. Au lieu de cela, il inclut une « revendication de dépassement de quota » dans le jeton qui indique que le consommateur de celui-ci doit interroger l’API Microsoft Graph pour récupérer les appartenances de l’utilisateur aux groupes. Pour plus d’informations sur l’utilisation des revendications de dépassement, consultez Revendications dans les jetons d’accès. Il est possible d’émettre uniquement des groupes affectés à une application, bien que l’affectation basée sur un groupe nécessite l’édition Microsoft Entra ID P1 ou P2.

Magasin de données personnalisé

Les rôles d’application et les groupes stockent des informations sur les affectations d’utilisateurs dans le répertoire Microsoft Entra. Une autre option permettant de gérer les informations de rôle d’utilisateur disponibles pour les développeurs consiste à conserver les informations en dehors du répertoire dans un magasin de données personnalisé. Par exemple, dans une base de données SQL, un stockage de table Azure ou d’Azure Cosmos DB for Table.

L’utilisation du stockage personnalisé permet aux développeurs de personnaliser et de contrôler comment attribuer des rôles aux utilisateurs et comment les représenter. Toutefois, la flexibilité supplémentaire introduit également une plus grande responsabilité. Par exemple, aucun mécanisme n’est actuellement disponible pour inclure ces informations dans les jetons retournés par l’ID Microsoft Entra. Les applications doivent récupérer les rôles si les informations de rôle sont conservées dans un magasin de données personnalisé. La récupération des rôles est généralement effectuée à l’aide de points d’extensibilité définis dans le middleware disponible pour la plateforme utilisée pour développer l’application. Les développeurs sont responsables de la sécurisation correcte du magasin de données personnalisé.

Choisir une approche

En général, la solution conseillée est d’utiliser les rôles d’application. Les rôles d’application fournissent le modèle de programmation le plus simple et sont destinés aux implémentations RBAC. Toutefois, des exigences d’application spécifiques peuvent indiquer qu’une approche différente serait une meilleure solution.

Les développeurs peuvent utiliser des rôles d’application pour contrôler si un utilisateur peut se connecter à une application, ou une application peut obtenir un jeton d’accès pour une API web. Les rôles d’application sont préférés aux groupes Microsoft Entra par les développeurs lorsqu’ils souhaitent décrire et contrôler les paramètres d’autorisation dans leurs applications. Par exemple, une application utilisant des groupes pour l’autorisation rencontre des problèmes pour le locataire suivant, puisque l’identificateur et le nom du groupe peuvent être différents. Une application utilisant des rôles d’application reste sécurisée.

Bien que les rôles d’application ou les groupes puissent être utilisés pour l’autorisation, les différences clés entre elles peuvent influencer la meilleure solution pour un scénario donné.

Rôles d'application Groupes Microsoft Entra Magasin de données personnalisé
Modèle de programmation simple Plus simple. Ils sont spécifiques à une application et sont définis dans l’inscription de l’application. Ils suivent l’application. Plus complexe. Les identificateurs de groupe varient entre les locataires et les revendications de dépassement peuvent être prises en compte. Les groupes ne sont pas spécifiques à une application, mais à un locataire de Microsoft Entra. Plus complexe. Les développeurs doivent implémenter les moyens par lesquels les informations de rôle sont stockées et récupérées.
Les valeurs de rôle sont statiques entre les locataires Microsoft Entra Oui Non Dépend de l’implémentation.
Les valeurs de rôle peuvent être utilisées dans plusieurs applications Non (sauf si la configuration du rôle est dupliquée dans chaque inscription d’application.) Oui Oui
Informations stockées dans le répertoire Oui Oui Non
Les informations sont fournies via des jetons Oui (revendication de rôles) Oui (En cas de dépassement de quota, les revendications des groupes peuvent devoir être récupérées au moment de l’exécution) Non (récupéré au moment de l’exécution via du code personnalisé.)
Durée de vie Réside dans l’inscription d’application dans l’annuaire. Supprimé lorsque l’inscription de l’application est supprimée. Réside dans l’annuaire. Rester intact même si l'enregistrement de l'application est supprimé. Vit dans un entrepôt de données personnalisé. Non lié à l’inscription de l’application.

Étapes suivantes

  • Last updated on