Valentina Casola » 6.Role Based Access Control standard (v3)

Role-Based Access Control

User's change frequently, Roles don't.

Privilege

• Roles are engineered based on the principle of least privileged
  • A role contains the minimum amount of permissions to instantiate an object.
• A user is assigned to a role that allows him or her to perform only what’s required for that role.
• No single role is given more permission than the same role for another user.

Role and transactions

• A role can be thought of as a set of transactions that a user can perform within the context of an organization.

• Note that the term transaction is used to extend the actions to not only read/write ones but to all actions that a user can perform on both functions and data (data absraction model).

Formal description

3 key concepts:

• Active Role: AR().
• Role set: RA().
• Transaction authorized per role: TA().

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}.

Basic rules

1. Role Assignment:
   A subject can execute a transaction only if the subject has selected or been assigned a role: ∀s: subject, t: tran(exec(s,t) → AR(s) ≠ 0).
2. Role Authorization:
   A subject’s active role must be authorized for the subject: ∀s: subject(AR(s) ⊆ RA(s)).
   
3. Transaction Authorization:
   A subject can execute a transaction only if the transaction is authorized for the subject’s active role: ∀s: subject, t: tran(exec(s,t) → t ∈ TA(RA(s))).
   

RBAC standard v3

• Core Components.
• Constraining Components
  • Hierarchical RBAC
    • General.
    • Limited.
  • Separation of Duty Relations
    • Static.
    • Dynamic.

Core Components

Defines:

1. Users.
2. Roles.
3. Operations (Ops).
4. Objects (obs).
5. User Assignments (ua): assigned_users.
6. Permissions (prms)
   • Assigned Permissions.
   • Object Permissions.
   • Operation Permissions.
7. Sessions
   • User Sessions.
   • Available Session Permissions.
   • Session Roles.

Core RBAC

USERS and ROLES

ROLE: An organizational job function with a clear definition of inherent responsibility and authority (permissions).

User Assignment

Permissions

The set of permissions that grants the approval to perform an operation on a protected object.

PA: Permissions Assignment

Mapping of permissions to objects.

PA: Permissions Assignment (cont’d)

RH (Role Hierarchies)

• Natural means of structuring roles to reflect organizational lines of authority and responsibilities.
• General and Limited.
• Define the inheritance relation among roles
  i.e. r₁ inherits r₂.

Tree Hierarchies

General RH

Limited RH

A restriction on the immediate descendants of the general role hierarchy.

Constrained RBAC

Separation of Duties

• Enforces conflict of interest policies employed to prevent users from exceeding a reasonable level of authority for their position.
• Ensures that failures of omission or commission within an organization can be caused only as a result of collusion among individuals.
• Two Types
  • Static Separation of Duties (SSD).
  • Dynamic Separation of Duties (DSD).

SSD

• SSD places restrictions on the set of roles and in particular on their ability to form UA relations.
• No user is assigned to n or more roles from the same role set, where n or more roles conflict with each other.
• A user may be in one role, but not in another—mutually exclusive.
• Prevents a person from submitting and approving their own request.

SSD in Presence of RH

• A constraint on the authorized users of the roles that have an SSD relation.
• Based on the authorized users rather than assigned users.
• Ensures that inheritance does not undermine SSD policies.
• Reduces the number of potential permissions that can be made available to a user by placing constraints on the users that can be assigned to a set of roles.

DSD

• Places constraints on the users that can be assigned to a set of roles, thereby reducing the number of potential prms that can be made available to a user.
• Constraints are across or within a user’s session.
• No user may activate n or more roles from the roles set in each user session.
• Timely Revocation of Trust ensures that prms do not persist beyond the time that they are required for performance of duty.

Policy-based access control mechanisms

Why Policies?

• Aggregate users.
• Aggregate resources.
• Aggregate simple security statements.

Access Control Model and Role Management

• Access Control Model based on attributes of users and on attributes of objects (different external conditions). There is the need of a model to better represent the structure of an organization or the relations btw users.
• Role could not be expressed just as a static member of a group.
• RBAC.

Open issues:

• People don’t understand complex systems or complex policies.
• it is hard work to map user security statements in enforceable policies.

Further Readings and references

• Access Control Mechanisms – CAP 15, Matt Bishop
  • Access Control Lists.
  • Capability lists.

Sun’s XACML Implementation:

• XACML Core Specification Documents [access_control-xacml-2.0-core-spec-os.pdf].
• Survey on XML-Based Policy Languages for Open Environments [Mariemma I. Yagüe].