> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Comprenez le concept du contrôle d'accès basé sur les rôles et la façon dont il s'applique à Auth0.
# Contrôle d'accès basé sur les rôles
Le contrôle d'accès basé sur les rôles (RBAC) consiste à attribuer des permissions aux utilisateurs en fonction de leur rôle au sein d'une organisation. Il offre une approche simple et facile à gérer de la gestion des accès, moins sujette aux erreurs que l'attribution individuelle de permissions aux utilisateurs.
Lorsque vous utilisez le RBAC pour la gestion des rôles, vous analysez les besoins de vos utilisateurs et les regroupez en rôles selon leurs responsabilités communes. Vous attribuez ensuite un ou plusieurs rôles à chaque utilisateur, ainsi qu'une ou plusieurs permissions à chaque rôle. Les relations utilisateur-rôle et rôle-permissions simplifient l'attribution des utilisateurs, puisque ceux-ci n'ont plus à être gérés individuellement et disposent plutôt de privilèges conformes aux permissions attribuées à leur ou leurs rôles.
Par exemple, si vous utilisiez le RBAC pour contrôler l'accès à une application RH, vous pourriez attribuer aux gestionnaires RH un rôle qui leur permet de mettre à jour les renseignements des employés, tandis que les autres employés ne pourraient consulter que leurs propres renseignements.
Lors de la planification de votre stratégie de contrôle d'accès, il est recommandé d'attribuer aux utilisateurs le nombre minimal de permissions nécessaire pour accomplir leur travail.
Pour un modèle d'autorisation plus robuste, consultez [l'autorisation fine (FGA)](https://docs.fga.dev/authorization-concepts) pour l'autorisation basée sur les attributs et les relations.
## Avantages du RBAC
Avec le RBAC, la gestion des accès est plus simple, à condition de respecter rigoureusement les exigences des rôles. Le RBAC vous aide à :
* créer une attribution systématique et reproductible des permissions
* vérifier facilement les privilèges des utilisateurs et corriger les problèmes relevés
* ajouter et modifier rapidement des rôles, ainsi que les déployer dans l’ensemble des API
* réduire le risque d’erreur lors de l’attribution des permissions aux utilisateurs
* intégrer des utilisateurs tiers en leur attribuant des rôles prédéfinis
* respecter plus efficacement les exigences réglementaires et légales en matière de confidentialité et de protection des renseignements personnels
## Modèle RBAC
### Rôles
Essentiellement, un rôle est un ensemble de permissions que vous pouvez attribuer aux utilisateurs. L’utilisation des rôles facilite l’ajout, la suppression et l’ajustement des permissions, plutôt que de les attribuer individuellement à chaque utilisateur. À mesure que votre base d’utilisateurs gagne en taille et en complexité, les rôles deviennent particulièrement utiles.
Vous pouvez aussi utiliser les rôles pour regrouper des permissions définies pour diverses API. Par exemple, supposons que vous ayez un module marketing qui permet aux utilisateurs de créer et de distribuer des infolettres aux clients. Votre spécialiste du contenu marketing crée toutes les infolettres et les prépare pour la distribution. De même, vous avez un module d’événements qui permet aux utilisateurs de créer, de publier et de gérer les inscriptions aux événements. Votre coordonnateur d’événements crée les événements. Une fois que le vice-président du marketing approuve les infolettres et les événements, son adjoint publie les événements et distribue les infolettres. Dans ce cas, votre API d’infolettres pourrait avoir une permission `distribute:newsletters` et votre API d’événements pourrait avoir une permission `publish:events`. Ces permissions pourraient ensuite être regroupées dans un rôle appelé `Marketing Publisher` et attribuées à l’adjoint du vice-président du marketing.
De plus, des rôles propres à l’organisation peuvent être [ajoutés aux membres de l’organisation](/docs/fr-ca/manage-users/organizations/configure-organizations/add-member-roles) et utilisés pour autoriser l’accès à votre application selon les organisations avec lesquelles un utilisateur final se connecte. Cela est particulièrement utile pour les produits SaaS et multilocataires, où un même utilisateur peut avoir un rôle privilégié dans une organisation, mais pas dans d’autres.
## Chevauchement des attributions de rôles
RBAC est un modèle additif. Donc, si vous avez des attributions de rôles qui se chevauchent, vos permissions effectives correspondent à l’union de ces attributions.
Par exemple, supposons que vous avez une API qui fournit des données pour une application de gestion d’événements. Vous créez un rôle `Organizer` et lui assignez des permissions qui lui permettent de consulter, de créer et de modifier des événements. Vous créez aussi un rôle `Registrant` et lui assignez des permissions qui lui permettent de consulter les événements et de s’y inscrire. Les utilisateurs qui ont à la fois les rôles `Organizer` et `Registrant` pourront consulter, créer, modifier et gérer les inscriptions aux événements.
## Contrôle d’accès basé sur les rôles dans Auth0
À l’heure actuelle, nous proposons deux façons de mettre en œuvre le contrôle d’accès basé sur les rôles (RBAC), que vous pouvez utiliser à la place du système interne de contrôle d’accès de votre API ou en complément de celui-ci :
* [Authorization Core](/docs/fr-ca/manage-users/access-control/configure-core-rbac)
* [Authorization Extension](/docs/fr-ca/customize/extensions/authorization-extension)
Nous élargissons l’ensemble de fonctionnalités Authorization Core afin qu’il offre les mêmes fonctionnalités que l’Authorization Extension. Notre nouvelle mise en œuvre centrale du RBAC améliore les performances et l’évolutivité, et finira par offrir un système RBAC plus souple que l’Authorization Extension.
Pour le moment, les deux mettent en œuvre les fonctionnalités clés du RBAC et vous permettent de restreindre les scopes personnalisés définis pour une API à ceux qui ont été attribués à l’utilisateur en tant que permissions. Pour une comparaison, consultez [Authorization Core vs. Authorization Extension](/docs/fr-ca/manage-users/access-control/authorization-core-vs-authorization-extension).
L’ensemble de fonctionnalités [Authorization Core](/docs/fr-ca/manage-users/access-control/rbac) et [Authorization Extension](/docs/fr-ca/customize/extensions/authorization-extension) sont deux fonctionnalités entièrement distinctes. Pour gérer les groupes, les rôles ou les permissions, vous devez utiliser la fonctionnalité dans laquelle ils ont été créés à l’origine.
Bien que la [Delegated Administration Extension (DAE)](/docs/fr-ca/customize/extensions/delegated-administration-extension) et l’ensemble de fonctionnalités [Authorization Core](/docs/fr-ca/manage-users/access-control/rbac) soient deux fonctionnalités entièrement distinctes, vous pouvez utiliser l’ensemble de fonctionnalités Authorization Core pour créer et gérer des rôles pour la DAE à l’aide d’Actions. Pour savoir comment faire, consultez [Sample Use Cases: Actions with Authorization](/docs/fr-ca/manage-users/access-control/sample-use-cases-actions-with-authorization).
### Étendre le RBAC
Vous pouvez offrir un contrôle accru en utilisant les [Actions](/docs/fr-ca/customize/actions) pour restreindre l’accès en fonction d’une combinaison d’attributs, comme le département de l’utilisateur, le moment de la journée, l’endroit d’où l’accès est effectué, ou tout autre attribut de l’utilisateur ou de l’API (par exemple, le username, l’habilitation de sécurité ou le nom de l’API).
Pour en savoir plus sur l’utilisation des Actions avec les politiques d’autorisation, consultez [Sample Use Cases: Actions with Authorization](/docs/fr-ca/manage-users/access-control/sample-use-cases-actions-with-authorization).
## En savoir plus
* [Activer le contrôle d’accès basé sur les rôles pour les API](/docs/fr-ca/get-started/apis/enable-role-based-access-control-for-apis)