RoleBased Access Control

1
Role-Based Access Control

• CSCE 522
• Fall 2002

2
Readings and Assignments

• Reading for Oct. 21
• Sandhu et al. Role-Based Access Control Models
• http//www.list.gmu.edu/journal_papers1.htm
• Article 19

3
RBAC Motivation

• Multi-user systems
• Multi-application systems
• Permissions are associated with roles
• Role-permission assignments are persistent v.s.
  user-permission assignments
• Intuitive competency, authority and
  responsibility

4
Motivation

• Express organizational policies
• Separation of duties
• Delegation of authority
• Flexible easy to modify to meet new security
  requirements
• Supports
• Least-privilege
• Separation of duties
• Data abstraction

5
RBAC

• Allows to express security requirements but
• CANNOT ENFORCE THESE PRINCIPLES
• e.g., RBAC can be configured to enforce BLP rules
  but its correctness depend on the configuration
  done by the system security officer.

6
Roles

• User group collection of user with possibly
  different permissions
• Role mediator between collection of users and
  collection of permissions
• RBAC independent from DAC and MAC (they may
  coexist)
• RBAC is policy neutral configuration of RBAC
  determines the policy to be enforced

7
RBAC
RBAC3 consolidated model
RBAC1 role hierarchy
RBAC2 constraints
RBAC0 base model
8
RBAC0
U Users
User assignment
Permission assignment
R Roles
P Permissions
. .
.
S Sessions
9
RBAC0

• User human beings
• Role job function (title)
• Permission approval of a mode of access
• Always positive
• Abstract representation
• Can apply to single object or to many

10
RBAC0

• UA user assignments
• Many-to-many
• PA Permission assignment
• Many-to-many
• Session mapping of a user to possibly may roles
• Multiple roles can be activated simultaneously
• Permissions union of permissions from all roles
• Each session is associated with a single user
• User may have multiple sessions at the same time

11
RBAC0 Components

• Users, Roles, Permissions, Sessions
• PA ? P x R (many-to-many)
• UA ? U x R (many-to-many)
• user S ? U, mapping each session si to a single
  user user(si)
• roles S ? 2R, mapping each session si to a set
  of roles roles(si) ? r (user(si),r) ? UA and
  si has permissions ? r?roles(si) p (p,r) ? PA

12
RBAC0

• Permissions apply to data and resource objects
  only
• Permissions do NOT apply to RBAC components
• Administrative permissions modify U,R,S,P
• Session under the control of user to
• Activate any subset of permitted roles
• Change roles within a session

13
RBAC1
Role Hierarchy
14
RBAC1

• Structuring roles
• Inheritance of permission from junior role
  (bottom) to senior role (top)
• Partial order
• Reflexive
• Transitive
• Anti-symmetric

15
RBAC1 Components

• Same as RBAC0 Users, Roles, Permissions,
  Sessions, PA ? P x R, UA ? U x R, user S ? U,
  mapping each session si to a single user user(si)
• RH ? R x R, partial order (? dominance)
• roles S ? 2R, mapping each session si to a set
  of roles roles(si) ? r (?r ? r)
  (user(si),r) ? UA and si has permissions ?
  r?roles(si) p (?r ? r) (p,r) ? PA

16
RBAC1
Role Hierarchy
Specialist Physician
Primary-care Physician
Inheritance of privileges
Physician
Health-care provider
17
RBAC1
Private Roles
Limit scope of inheritance
Project Supervisor
Project Supervisor
Test Engineer
Programmer
Test Engineer
Programmer
Test Engineer
Programmer
Project Member
Project Member
18
RBAC2 Constraints

• Enforces high-level organizational policies
• Management of decentralized security
• Constraints define acceptable and not
  acceptable accesses

19
RBAC2 Components

• Same as RBAC0 Constraints

20
RBAC2
U Users
User assignment
Permission assignment
R Roles
P Permissions
. .
.
S Sessions
21
RBAC2

• Mutually exclusive roles
• Dual constraint of permission assignments
  (permission assigned to at most one mutually
  exclusive role)
• Cardinality constraints (e.g., of roles an
  individual can belong)
• Prerequisite roles

22
RBAC2

• Constraints can apply to sessions, user and roles
  functions

23
RBAC3