RBAC Concepts and Applications

Access Control

• Role-based Access Control (RBAC) regulates object access based on user roles within an organization.
• Formal access control approaches emerged in the early 1970s, including Discretionary Access Control (DAC) and Mandatory Access Control (MAC).
• MAC, driven by military needs, may be unsuitable for civilian use due to difficulties with least privilege, conflict-of-interest, and proper enforcement of access control.
• DAC focuses on civilian applications but assumes resource ownership by subjects whereas, in real-world organizations, resources are not owned.
• Ferraiolo and Kuhn (1992) proposed RBAC as a non-discretionary access control model to address these limitations.
• Sandhu et al. (1996) developed RBAC96, a framework defining modular RBAC models.
• NIST promoted RBAC standards, culminating in the INCITS 359-2004 standard (based on the NIST model for RBAC).
• A NIST revision from 2010 added attributes to RBAC, leading to the INCITS 359-2012 standard.

RBAC Components

• RBAC models comprise two classes of components:
  • Static Components: users, roles, permissions, and inter-relationships
  • Dynamic Components: subjects (programs), role authorization, and object access authorization.

Users, Roles, and Permissions

• User: an individual interacting directly with a computer system.
• Role: a set of actions and responsibilities associated with a specific job function.
• Permission: a description of authorized access to resources or tasks for a user or role. Permissions are generally positive, defining what a user or role is allowed to do. Constraints are negative, defining restrictions or limitations.

Static Components of RBAC Models

• U: set of users
• R: set of roles
• P: set of permissions
• UR ⊆ U × R (user-role assignment)
• RP ⊆ R × P (role-permission assignment)

Roles vs. Groups and Compartments

• Organizations typically use roles to define permissions instead of groups of users.
• Roles provide abstraction, making permission management easier, and are more stable than implementation-specific groups, which might change.
• Roles are independent of implementation but group allocation might be.

Subjects and Sessions

• Session: an instance of a user's interaction with a system.
• Subject: a running computer program (process) acting on behalf of a user.

Dynamic Components of RBAC Models

• Subjects (S): running computer programs.
• Su: subject-to-user mapping (S → U)
• Sr: subject-to-role mapping (S → P(R)) - a subject can have multiple active roles
• UR(su(s)): set of roles for a particular subject based on its user.

Role and Object Authorization

• A subject can only have active roles authorized by its user.
• Object access authorization: a subject can perform an operation (op) on an object (o) if the subject has an active role (r) that has access permission (p) for that operation on that object.

Conceptual Level vs. System Level

• RBAC models abstract system-level components (users, roles, and permissions) at a conceptual level. This helps in managing access rights and permissions independent of the system's particular mechanisms.

Hierarchical RBAC

• Roles often overlap in organizations.
• Role heirarchy: roles can inherit permissions from parent roles
• Hierarchy allows less powerful roles to inherit permissions from more powerful roles.

Inheritance Schemes

• Permission-based inheritance: a role inherits the permissions of all parent roles.
• User and permission-based inheritance: a role inherits permissions and the users assigned to those permissions.
• User-based inheritance: a role inherits users associated with parent roles.

Role Authorized Users and Permissions

• User authorization: Users in RBAC are granted certain roles and, in inheritance models, those users are authorized for roles that inherit their parent roles.
• Permission authorization: Permissions granted to a role are granted to all inheriting roles.
• Powerful roles can utilize permissions of less powerful ones based on inheritance hierarchies.

Constrained RBAC

• Constraints improve system design, control role assignments and permissions, handle mutual exclusions (only one role can be used by a user at a time), prerequisite roles, and other aspects.
• Includes static constraints enforced on basic objects such as users, roles, permissions, and the relationships between them.
• Dynamic constraints, enforce rules throughout the use of the system.

Separation of Duty (SoD)

• SoD divides responsibility for sensitive tasks to prevent any single individual from compromising system security.
• Static SoD (SSD): constraints imposed on assigned roles at the point when users are authorized for them
• Dynamic SoD (DSD): constraints invoked during system execution while users are actively using the system, enforcing further restrictions and constraints.

Operational SoD

• Overall, SoD prevents a user from having total control or performing all operations within a critical function or system.

Consolidated RBAC

• Consolidated RBAC combines hierarchical and constrained RBAC aspects.

RBAC, DAC, and MAC

• RBAC isn't a direct substitute for DAC or MAC as it's typically too costly.
• Combining RBAC with DAC or MAC is more common than direct implementation of one type through another.

RBAC Implementations

• RBAC implementation typically integrates with enterprise IT infrastructures (e.g., workflow management systems, web applications, operating systems, distributed file systems).
• Specific examples of integrations exist for Java, Oracle, and Microsoft Azure.

Concluding Remarks

• RBAC simplifies security administration, reduces costs due to frequent employee roles changes, supports diverse policies like DAC and MAC, and is adaptable for a broad range of applications and environments.