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

  • Article

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 contrôle d’accès en fonction du rôle (RBAC) de l’application est différent 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 d’Azure et les rôles intégrés font tous deux partie du RBAC Azure, qui permet de gérer les ressources Azure. Le contrôle d’accès en fonction du rôle Microsoft Entra 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 de RBAC spécifiques à l’application, voir Procédure : ajouter des rôles d’application dans votre application et les recevoir dans le jeton.

Définitions de rôles

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

Le RBAC aide un développeur d’applications à gérer les ressources et leur utilisation. Le 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 les utilisateurs qui ont accès à une application à l’aide de la propriété Affectation de l'utilisateur obligatoire. Les développeurs doivent prendre en compte des utilisateurs spécifiques au sein de l’application et ce que les utilisateurs peuvent faire dans 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 du centre d’administration Microsoft Entra. La définition de rôle comprend une valeur qui est retournée pour les utilisateurs affectés à ce rôle. Le développeur peut ensuite utiliser cette valeur pour implémenter la logique d’application afin de déterminer ce que ces utilisateurs peuvent ou non faire dans une application.

Options du RBAC

Les recommandations suivantes doivent être appliquées 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é Microsoft prend en charge plusieurs solutions qui peuvent être utilisées pour appliquer, stocker et récupérer les informations de rôle pour les utilisateurs authentifiés. Ces solutions incluent les rôles d’application, les groupes Microsoft Entra et l’utilisation de banques de données personnalisées 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 permissions 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. En général, les applications reçoivent les informations de rôle d’utilisateur sous forme de revendications, puis décident des autorisations de l’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.

Quand Microsoft Entra ID émet un jeton d’accès pour un utilisateur ou une application authentifiés, il inclut les noms des rôles que vous avez attribués à l’entité (l’utilisateur ou l’application) dans la revendication roles du 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 revendication roles.

Groupes

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

Important

Lorsque vous travaillez avec des groupes, les développeurs doivent être au fait du concept de revendication de dépassement. Par défaut, si un utilisateur est membre de plus de la limite de dépassement (150 pour les jetons SAML, 200 pour les jetons JWT et 6 en cas d’utilisation du flux implicite), Microsoft Entra ID n’émet pas de revendication de groupes dans le jeton. Au lieu de cela, il inclut une « revendication de dépassement » dans le jeton qui indique au consommateur du jeton d’interroger l’API Microsoft Graph pour récupérer l’appartenance de groupe de l’utilisateur. 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 qui sont assignés à une application, bien que l’attribution basée sur le groupe nécessite une édition Microsoft Entra ID Premium P1 ou P2.

Magasin de données personnalisé

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

L’utilisation du stockage personnalisé permet aux développeurs d’appliquer des personnalisations et des contrôles supplémentaires sur la façon d’attribuer des rôles aux utilisateurs et de les représenter. Toutefois, cette flexibilité supplémentaire découle également sur une plus grande responsabilité. Par exemple, aucun mécanisme n’est actuellement disponible pour inclure ces informations dans les jetons retournés par Microsoft Entra ID. 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 s’effectue généralement à l’aide de points d’extensibilité définis dans l’intergiciel disponible pour la plateforme utilisée pour développer l’application. Les développeurs sont responsables de la sécurisation du magasin de données personnalisé.

Avec les stratégies personnalisées Azure AD B2C, il est possible d’interagir avec les magasins de données personnalisés et d’inclure des revendications personnalisées dans un jeton.

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 du contrôle d’accès en fonction du rôle. Toutefois, certaines exigences spécifiques à l’application peuvent faire qu’une autre approche serait une meilleure solution.

Les développeurs peuvent utiliser les rôles d’application pour contrôler si un utilisateur peut se connecter à une application ou si une application peut obtenir un jeton d’accès pour une API web. Les rôles d’application ont la faveur des développeurs par rapport aux groupes Microsoft Entra, lorsqu’ils souhaitent décrire et contrôler eux-mêmes les paramètres d’autorisation dans leurs applications. Par exemple, une application qui utilise des groupes pour l’autorisation s’arrête au locataire suivant, car l’identificateur de groupe et le nom peuvent être différents. Une application utilisant des rôles d’application reste sûre.

Bien qu’il soit possible d’utiliser des rôles ou des groupes d’application pour l’autorisation, les principales différences entre ces possibilités peuvent déterminer la meilleure solution pour un scénario donné.

Rôles d’application Groupes Microsoft Entra Magasin de données personnalisé
Modèle de programmation Plus simple. Les groupes sont spécifiques à une application et 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 Microsoft Entra. Plus complexe. Les développeurs doivent implémenter des 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 de rôle est dupliquée dans chaque inscription d’application.) Oui Oui
Informations stockées dans l’annuaire Oui Oui Non
Informations fournies via des jetons Oui (revendication de rôles) Oui (en cas de dépassement, les revendications de groupes peuvent devoir être récupérées lors 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 d’application est supprimée. Réside dans l’annuaire. Reste intact même lorsque l’inscription d’application est supprimée. Réside dans le magasin de données personnalisé. Non lié à l’inscription d’application.

Étapes suivantes