ROLE BASED ACCESS
CONTROL
ETHAN BLISS
Introduction
• The need for access control began with multi-user
and multi-application computers in the 1970s
• System administrator must ensure only authorized
users can access certain data and resources
• Access Control is a means by which access is
enabled or restricted
• Who can access
• Type of access
• Rule Based Access Control (RBAC) introduced in
1992 by Ferraiolo and Kuhn
Terminology
User: person who uses the computer system
Session: an instance of a user’s dialog with a system
Subject: a computer process run by a user
Object: a resource accessible on a computer
system
• Operation: an active process invoked by a subject
• Permission: authorization to perform an action
•
•
•
•
Role Based Access Control
• With Role-Based Access Control (RBAC), access to
objects is based on a user’s role in an organization
• A role is essentially a collection of permissions
RBAC Rules
• Role assignment:
• Subject can execute transaction only if subject has been
assigned to a role
• All users required to have a role
• Role authorization:
• Subject’s role must be authorized for the subject
• Users can only take on a role they are authorized for
• Transaction authorization:
• Subject can execute transaction only if transaction
authorized for subject’s role
• Users can only execute transactions they are authorized to
RBAC Security Support
• RBAC supports three well-known security principles:
• Least Privilege
• only those permissions required for tasks conducted by
members of the role are assigned to role.
• Separation of duties
• ensure that mutually exclusive roles must be invoked to
complete a sensitive task
• Data Abstraction
• supported by means of abstract permissions such as credit
and debit for an account.
RBAC Implementation
• RBAC implementation ranges from simple to
complex
• Cannot be treated as a single model
• Issues of scope and terminology
• Wide variety of technology and choices
• Many models use different terminology to describe the
same concepts
• RBAC standardization was proposed by NIST(
National Institute of Standards and Technology).
RBAC Standard
RBAC Reference Model
• Four Components
• Core RBAC
• Hierarchical RBAC
• Limited Hierarchies
• General Hierarchies
• Static Constrained RBAC
• Without Hierarchies
• With Hierarchies
• Dynamic Constrained RBAC
Functional Specification
• Set of functional components
RBAC Reference Model
• Defined in terms of four model components
•
•
•
•
Core RBAC
Hierarchical RBAC
Static Separation of Duty Relations
Dynamic Separation of Duty Relations
• Provide standard vocabulary
• Define broad range of RBAC features
Core RBAC
• The essential elements of RBAC
1.
2.
3.
4.
5.
Users
Roles
Permissions, composed of
Operations applied to
Objects
• Access policy constructed around role
• Users assigned to roles
• Permissions associated with roles
Core RBAC Mapping
• Static: do not involve a
subject
• Users assigned to roles
• Roles assigned permissions
• Dynamic: subject access
• Subject mapped to single
user
• User may be mapped to
multiple subjects
• Subject mapped to role set
Hierarchical RBAC
• Adds requirements for supporting role hierarchies
• Inheritance relationship among roles
• Parent roles acquire permission of children
• Children acquire user membership of parents
• Two types
• General: allow a role to have more than one immediate
ascendant and descendant
• Limited: impose restrictions to generate simpler tree
structure
• 1+ immediate ascendants but one descendent
• Vice versa
General Hierarchy
• Multiple inheritance
• Combine functional and organizational roles
Constrained RBAC
• Adds separation of duty (SoD) relations to RBAC
model
• Critical operations are divided among 2+ people
• No single individual can compromise security
• Minimize likelihood of collusion
• Used to enforce conflict of interest policies
• Allows both static and dynamic SoD
Static SoD
• Enforce constraints on assignment of users to roles
• If a user is assigned to one role, the user is prohibited from
being a member of a second role
• Roles may be mutually exclusive
• Conflicting permissions assigned to these roles
• Defined with and without hierarchy
• Static SoD with hierarchy: both inherited and directly
assigned roles considered
Static SoD Example
• Billing clerk and
accounts receivable
clerk mutually
exclusive
• Deters fraud
Dynamic SoD
• Also limit permissions available to a user
• Users may be authorized for conflicting roles
• Limitations imposed while the user is logged on
• No user may be active in both roles at once
• Dynamic SoD prevents applying conflicting privileges in the
same session
• Assumes a user cannot terminate a session and log
on with another role
RBAC Functional Specification
• Defines features required of RBAC system
Three categories
• Administrative Operations
• Create, delete, maintain RBAC elements and relations
• Administrative Reviews
• Query operations on RBAC elements and relations
• System level functionality
• Creation of user sessions
• Role activation/deactivation
• Enforcement of role activation constraints
RBAC, MAC, and DAC
DAC (Dynamic Access Control)
• Creators or owners of files assign access rights
• Subject with discretionary access can pass
information to another subject
MAC (Mandatory Access Control)
• Access control system mediates all access to
objects
• Users cannot give away permissions
RBAC
• More general
• Can implement both MAC and DAC
DAC using RBAC
• More theoretical than practical
• RBAC is nondiscretionary in nature
• Implemented using roles associated with each
object
• Four roles and eight permissions for each object
• Roles: OWN, PARENT, PARENTwithGRANT, READ
• Permissions associated to roles: CanRead, DestroyObject,
etc.
• Allow authorized users to assign other users to roles
MAC using RBAC
Easier than implementing DAC
Combine role hierarchies and constraints
Two role hierarchies, one for read and one for write
High security levels on top of read and bottom of
write
• Read/Write permissions for objects assigned to roles
based on security level
•
•
•
•
Questions?