Vue d'ensemble du contrôle d'accès basé sur les attributs

Le contrôle d'accès basé sur les attributs (ABAC) est un modèle d'autorisation qui évalue les attributs pour déterminer l'accès. Les attributs peuvent concerner le sujet (l'utilisateur ou l'entité qui demande l'accès), l'objet (la ressource ou le fichier auquel le sujet veut accéder) ou même l'environnement (d'autres paramètres tels que l'heure de la journée, l'adresse IP, etc.)

Les politiques ABAC fonctionnent parallèlement au RBAC (contrôle d'accès basé sur les rôles) et aux divisions pour fournir une plus grande granularité de contrôle d'accès. Ces politiques sont des énoncés logiques booléens dans lesquels une condition est évaluée à un résultat vrai ou faux. Chaque politique cible un groupe spécifique d'appels API (appelé cible) et s'applique à un sous-ensemble spécifique d'utilisateurs (appelés sujets).

Pour commencer à utiliser ABAC, active d'abord le contrôle d'accès basé sur les attributs.

Actuellement, les politiques suivantes sont prises en charge :

Cannot grant new roles - Empêche les utilisateurs non-administrateurs d'attribuer des rôles qu'ils n'ont pas eux-mêmes.
Impossible de mettre à jour certains champs du profil de l'utilisateur - Empêche la modification des champs définis du profil de l'utilisateur, sauf par les superviseurs ou les administrateurs.

Définitions utilisées dans ABAC

Terme	Description
Nom de la politique	Le nom de la politique défini par le créateur de la politique lors de la création ou de la mise à jour de la politique.
Description	(Facultatif) Brève description de la politique définie par le créateur de la politique.
Cible	La ressource ciblée à laquelle la politique s'applique. Les cibles de ressources prennent la forme de `domain:entity:action` et reflètent l'action que le sujet tente d'effectuer (`directory:userprofile:edit`). La cible reflète ce que l'utilisateur essaie de faire et correspond généralement à un appel à l'API pour modifier, consulter ou supprimer une ressource. Les politiques sont associées à des objectifs.
Objet	Le sujet d'une politique est l'utilisateur, le groupe ou le client auquel la politique s'applique. Les politiques ne peuvent avoir qu'un seul sujet. Le sujet a les membres suivants : type: Indique si une politique s'applique à un utilisateur unique, à un groupe d'utilisateurs, à un client OAuth spécifique ou à tous les utilisateurs/clients accédant à la ressource. L'attribut type doit être l'un des suivants : utilisateur, groupe, client ou tous. id: Le GUID de l'utilisateur/groupe/client. Lorsque le type de sujet est "tout", cette valeur est ignorée.
Effet	L'effet d'une politique indique si elle autorise l'accès lorsque ses conditions sont remplies ou si elle le refuse immédiatement lorsque les conditions sont remplies. Si un utilisateur remplit les conditions d'une politique ALLOW, dispose des autorisations requises et n'est pas bloqué par une politique DENY, il est autorisé à accéder à la ressource. ABAC ne remplace pas les contrôles d'accès basés sur les rôles et les contrôles d'accès divisionnaires existants. Il fonctionne en parallèle pour fournir un contrôle d'accès plus fin. Si le résultat de l'évaluation d'une politique ABAC est ALLOW, le système vérifie alors si le sujet dispose de l'autorisation nécessaire avant d'autoriser l'accès. Les politiques dont l'effet est DENY spécifient les conditions dans lesquelles l'accès à la ressource doit être refusé. Si un utilisateur remplit les conditions d'une politique DENY, l'accès lui est refusé, qu'il remplisse ou non les conditions d'une politique ALLOW sur la même ressource. Si une ressource est assortie d'au moins une politique, mais que l'utilisateur ne remplit les conditions d'aucune de ces politiques, l'accès à la ressource lui est refusé par défaut.
Condition	(Facultatif) Établit les conditions spécifiques dans lesquelles la politique autorise ou refuse l'accès. Chaque condition évaluée est représentée par le modèle de base suivant (représenté en JSON) : `"attribute.one": { "comparison_operation": "attribute.two" }` Lorsque la politique est évaluée, le système récupère les attributs correspondant aux noms d'attributs fournis et les compare à l'aide de l'opération fournie. Plusieurs conditions peuvent également être imbriquées dans une structure Any (représentant le OU logique) ou All (représentant le ET logique), afin de permettre une logique de condition plus complexe.
Attributs prédéfinis	(Facultatif) Une carte d'attributs statiques prédéfinis qui sont comparés aux données d'attributs du système. Par exemple, le créateur de la politique peut vouloir autoriser l'accès à tout utilisateur ayant un identifiant de rôle spécifique, et il fournira l'identifiant de rôle en question en tant qu'attribut prédéfini dans la politique. Le créateur de la politique définit les noms d'attributs prédéfinis. Les noms qui entrent en conflit avec des attributs existants fournis par le système seront rejetés lors de la validation. Les noms des attributs prédéfinis peuvent contenir des caractères alphanumériques, des points (.) et des traits de soulignement ( _ ), mais pas d'espaces ni de caractères spéciaux autres que ceux énumérés. Chaque entrée de la carte possède une clé, qui est le nom de l'attribut prédéfini, et une valeur, qui est un objet TypedAttribute, avec les membres suivants : type: Le type de données de base de l'attribut. valeur: Une représentation sous forme de chaîne de la valeur de l'attribut.

Pour plus d'informations, voir Créer des politiques d'accès.