authorization/access_control_models

4 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

RBAC definition and characteristics

RBAC (Role-Based Access Control) is a model of access control in which access is granted or denied based upon the roles assigned to a user. Permissions are not directly assigned to an entity; rather, permissions are associated with a role and the entity inherits the permissions of any roles assigned to it. Generally, the relationship between roles and users can be many-to-many, and roles may be hierarchical in nature.

ABAC definition and characteristics

ABAC (Attribute-Based Access Control) is an access control model where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies specified in terms of those attributes and conditions (per NIST SP 800-162, pg. 7). Attributes are characteristics represented as name-value pairs and assigned to a subject, object, or the environment. Examples include job role, time of day, project name, MAC address, and creation date.

ReBAC definition and characteristics

ReBAC (Relationship-Based Access Control) is an access control model that grants access based on the relationships between resources. For instance, allowing only the user who created a post to edit it. This is especially necessary in social network applications like Twitter or Facebook where users want to limit access to their data to people they choose (friends, family, followers). Some systems support algebraic operators like AND and NOT to express policies such as 'if this user has relationship X but not relationship Y with the object, then grant access'.

ABAC and ReBAC advantages over RBAC

Although RBAC has a long history and remains popular, ABAC and ReBAC should typically be preferred for application development. Advantages include: (1) Support for fine-grained, complex Boolean logic. In RBAC, access decisions are made on presence or absence of roles; in ABAC, access decisions can incorporate multiple characteristics. ABAC can also incorporate environmental and dynamic attributes like time of day, type of device, and geographic location. ReBAC, since it supports assigning relationships between direct objects and direct users, allows for fine-grained permissions. (2) Robustness. In large projects with numerous roles, it is easy to miss or improperly perform role checks, resulting in too much or too little access. (3) Speed. RBAC can suffer from 'role explosion' where too many roles are defined, potentially exceeding transmission size limits. (4) Multi-tenancy and cross-organizational support. RBAC is poorly suited for distinct organizations needing access to the same protected resources. (5) Ease of management. Although initial RBAC setup is often simpler than ABAC, this short-term benefit quickly vanishes as system scale and complexity grow.

Give your agent this brain