J. Barkley, K. Besnozov. 1999. "Supporting Relationships in Access Control Using Role Based Access Control"

Consider access policies associated with content rating systems in entertainment media. A movie rated “PG13” may only be viewed by a minor over the age of 13 unless accompanied by an adult. An access decision for this policy includes the following factors:

• the age attribute of the user,
• the rating attribute of the object, i.e., the movie to which access is sought,
• the relationship, i.e., simultaneous access, with another user, and
• the age attribute of the other user.

- Using roles to express relationships may be inefficient and/or counter intuitive.
- When roles cannot be used to represent relationships, it is common to program access decision logic directly into an application. This approach restricts the ability to change access policy in a timely manner.



- Consider the relationship “attending-physician” between a physician and a patient.
- An authorization service may need to know if an attending physician relationship exists between patient Peter and the user with ID smith.

• In an RBAC system where a role is a data attribute of the user, this could be modeled by creating an “attending-physician-to-Peter” role. (very inefficient!)
  
  • the attending-physician relationship likely being redundantly stored in two locations: the patient record database and the role database;
  • security administrators having to update the role database whenever the attending-physician relationship changes for a user, and;
  • potentially very large active role sets when the user is a doctor

- relationships, as opposed to traditional security attributes such as roles, can have short lifetimes



RAD





The RAD facility is composed of the following elements:

• An Access Decider (AD) which receives requests for authorization decisions from RAD clients.
• Zero or more Policy Evaluators which provide evaluation decisions for those policies that govern access to the given resource. If a Policy Evaluator does not have any policy associated with the given resource name, the evaluator returns the result “don't know.”
• A Policy Evaluator Locator which provides references to potentially more than one Policy Evaluator.
• A Dynamic Attribute Service which provides dynamic attributes of the subject in the context of the intended access operation on the given resource associated with the specified resource name.
• A Decision Combinator which combines results of the evaluations made by Policy Evaluators into a final access decision by resolving evaluation conflicts and applying combination policies.

RAD vs other approaches
User attributes and relationships are usually stored in an information system as part of normal business processing, not for the purpose of access control. Requiring such information to also be stored as security metadata creates redundant information managed by different administrators
with different perspectives as to its use. In general, it is counter intuitive.

Another approach which is commonly used to include relationships and other factors in role based access decisions is to locate such access decision logic within application code. From a policy management point of view, this is very undesirable. Any time a policy changes, application code must be changed.

However, the ability to integrate access decisions made in different parts of an enterprise and the capability of including factors in access decision where the values of those factors are naturally very dynamic can result in unacceptable performance.