Attribute-based access control overview

Attribute-based access control (ABAC) is an authorization model that evaluates attributes to determine access. Attributes can relate to the subject (the user or entity requesting access), the object (the resource or file the subject wants to access), or even the environment (other parameters such as time of the day, IP address, and so on).

ABAC policies work alongside RBAC (role-based access control) and divisions to provide more access control granularity. These policies are Boolean logic statements where a condition is evaluated to a true or false result. Each policy targets a specific group of API calls (known as a target) and applies to a specific subset of users (known as the subjects).

To start using ABAC, enable attribute based access control first.

Currently, the following policies are supported:

Cannot grant new roles – Prevents non-admin users from granting roles that they do not themselves have
Cannot update certain user profile fields – Prevents defined user profile fields from being modified except by supervisors or admins

Definitions used in ABAC

Término	Descripción
Policy Name	The name of the policy set by the policy creator on policy creation or update.
Descripción	(Optional) A short description of the policy set by the policy creator.
Target	The targeted resource to which the policy applies. Resource targets take the form of `domain:entity:action` and reflect the action that the subject is attempting to perform (`directory:userprofile:edit`). The target reflects what the user is trying to do and typically equates to an API call to edit, view, or delete a resource. Policies are associated with targets.
Tema	The subject of a policy is the user, group, or client to which the policy applies. Policies may only have one subject. The subject has the following members: type: Indicates if a policy applies to a single user, a group of users, a specific OAuth client, or all users/clients accessing the resource. The type attribute must be one of the following: user, group, client, or all. id: The GUID of the user/group/client. When the subject type is all this value is ignored.
Effect	The effect of a policy indicates whether the policy allows access when its conditions are met, or immediately deny access when conditions are met. If a user meets the conditions of an ALLOW policy, has the requisite permissions, and is not blocked by a DENY policy, they are allowed access to the resource. ABAC does not replace the existing role-based access and divisional access controls. It works right alongside them to provide more fine-grained access control. If the result of an ABAC policy evaluation is ALLOW, the system then checks to see if the subject has the necessary permission before allowing access. Policies with an effect of DENY specify conditions under which access to the resource must be denied. If a user matches the conditions of a DENY policy, they are denied access regardless of whether they also match the conditions of an ALLOW policy on the same resource. If a resource has at least one policy attached but the user does not match the conditions for any of the policies, the user is denied access to the resource by default.
Condition	(Optional) Establishes specific conditions under which the policy allows or denies access. Each evaluated condition is represented by the following basic pattern (represented in JSON): `"attribute.one": { "comparison_operation": "attribute.two" }` When the policy is evaluated, the system retrieves the attributes corresponding to the supplied attribute names and compares them using the supplied operation. Multiple conditions may also be nested inside an Any (representing logical OR) or All (representing logical AND) structure, to allow for more complex condition logic.
Preset Attributes	(Optional) A map of static, pre-defined attributes that are compared against attribute data from the system. For example, the policy creator may want to allow access to any user with a specific role ID, and they would supply the role ID in question as a preset attribute in the policy. The policy creator sets the preset attribute names. Names that conflict with existing attributes supplied by the system will be rejected on validation. Preset attribute names can contain alphanumeric characters, periods (.), and underscores ( _ ) but not spaces or special characters other than the ones listed. Each map entry has a key, which is the name of the preset attribute, and a value, which is a TypedAttribute object, with the following members: type: The basic data type of the attribute. value: A string representation of the value of the attribute.

For more information, see Create Access Policies.