Role-Based Access Control (RBAC)

Assigns permissions to roles, which are collections of permissions related to specific job functions. 1

This style of access control aligns with how humans organize themselves within organizations by assigning job functions to roles. This model is simple and aligns well with how humans operate within their job function.

This model also helps to align security objectives with higher level organizational policy (.e.g. ethics, privacy, administration). This type of model requires centralized control and enforcement.

The act of granting membership and specifying transactions for a role is loosely analogous to the process of clearing users (granting membership) and the labeling (associate operation sensitivities) of objects … - Role-Based Access Controls by Ferraiolo, Kuhn Et el.

A role can be thought of as a set of transactions that a user or set of users can perform within the context of an organization. - Role-Based Access Controls by Ferraiolo, Kuhn Et el.

Roles are group oriented and they provide a means of naming and describing many-to-many relationships between individuals and rights.

For each subject, the active role is the one that the subject is currently using:
```
AR(s: subject) = { the active role for subject s}.
```
Each subject may be authorized to perform one or more roles:
```
RA(s: subject) = { authorized roles for subject s }.
```
Each role may be authorized to perform one or more transactions:
```
TA(r: role) = { transactions authorized for role r}.
```
Subjets may execute transactions. The predicate exec(s,t) is true if subject s can execute transaction t at the current time, otherwise it is false:
```
exec(s :subject, t: tran) = true iff subject `s` can execute transaction `t`
```

Three basic rules are required:

Role assignment: A subject can execute a transaction only if the subject has selected or been assigned a role
Role authorization: A subject’s active role must be authorized for the subject
Transaction authorization: A subject can execute a transaction only if the transaction is authorized for the subject’s active role

Another user of RBAC is to support integrity. One aspect of integrity is a requirement that data and processes be modified only in authorized ways by authorized users.

The problem of determining whether data have been modified only in authorized ways can be as complex as the transaction that did the modification. For this reason, the practical approach is for transactions to be certified and trusted. If transactions must be trusted then access control can be incorporated directly into each transaction.

RBAC makes a decision based on the subject’s association with a role. RBAC does not easily support multi-factor decisions. RBAC role assignments tend to be based upon more static organizational positions, presenting challenges in certain RBAC architectures where dynamic access control decisions are required (.e.g. CI_JOB_TOKEN). Trying to implement these kidns of access control decisoins would require the creation of numerous roles that are ad hoc and limited in membership, leading to what is often termed “role explosion”.

ABAC avoids the need for explicit authorizations to be directly assigned to individual subjects prior to a request to perform an operation on the object.

ABAC: An access control method where subject requests to perform operations on objets are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.

Attributes: characteristics of the subject, object, or environment conditions.
Subject: is a human or or non-person entity (NPE) that issues access requests to perform operations on objects.
Object: a system resource for which access is managed by the ABAC system
Operation: is the execution of a function at the request of a subject upon an object. (e.g. read, write, edit, delete, copy, execute and modify)
Policy: is the representation of rules or relationships that makes it possible to determine if a requested access should be allowed.
Environment conditions: operational or situational context in which the access request occurs.

Roles can inherit from each other and imply permissions. - 1

Role-Based Access Control (RBAC)

See also