Purdue Universityfshahidi/articles/Shahidi...Purdue University
lecture12 - Purdue University
Transcript of lecture12 - Purdue University
Role-Based Access Control Models.
R.S. Sandhu, E.J. Coyne, H.L. Feinstein, and C.E. Youman.
IEEE Computer, 29(2):38--47, February 1996.
3
RBAC96 Family of Models
RBAC3: Role Hierarchies + Constraints
RBAC0: BASIC RBAC
RBAC1: Role Hierarchies
RBAC2: Constraints
4
RBAC0
Users Roles
User-Role Assignment
Permissions
Permission-Role Assignment
Sessions
* * * *
1
*
*
*
5
RBAC0: Formal Modeln U, R, P, S (users, roles, permissions, and sessions)n PA ⊆ P × R (permission assignment)n UA ⊆ U × R (user assignment)n user: S → Un roles: S → 2R
n requires roles(s) ⊆ { r | (user(s), r) ∈ UA }
Session s has permissions
∪ r ∈ roles(s) { p | (p, r) ∈ PA }
6
Why RBAC
n Fewer relationships to managen from O(mn) to O(m+n), where m is the number of
users and n is the number of permissions
n Roles add a useful level of indirection
7
RBAC1: RBAC0+ Role Hierarchies
Primary-Care Physician
Specialist Physician
Physician
Health-Care Provider
8
RBAC1: Formal Modeln U, R, R, S, PA, UA, and user unchanged from RBAC0n RH ⊆ R × R : a partial order on R, written as ≥n roles: S → 2R
n requires roles(s) ⊆{ r | ∃ r’ [(r’ ≥ r) & (user(s), r’) ∈ PA] }
Session s has permissions
∪ r ∈ roles(s) { p | ∃ r’’ [(r ≥ r’’) & (p, r’’) ∈ PA] }
9
On Modeling Role Hierarchy As A Partial Ordern Modeling RH as a partial
order may miss some important information
n Consider the two examples to the rightn where the dashed edge is
added and removed
n Better approach seems to remember the base edges and then compute their transitive and reflexive closure
r1
r3
r2
r1
r3
r2
EX1:
EX2:
10
Semantics of Role Hierarchies
n User inheritancen r1≥r2 means every user that is
a member of r1 is also a member of r2
n Permission inheritancen r1≥r2 means every permission
that is authorized for r2 is also authorized r1
n Activation inheritancen r1≥r2 means that activating r1
will also activate r2
Physician
Health-Care Provider
12
Static Mutual Exclusion Constraints
n Two mutually exclusive roles: cannot both have the same user as members
n Two mutually exclusive roles: cannot both have the same permissionsn why?
n Two mutually exclusive permissions: one role cannot have both permissionsn why?
13
Cardinality Constraints
n On User-Role Assignmentn at most k users can belong to the rolen at least k users must belong to the rolen exactly k users must belong to the role
n On activationn at most k users can activate a rolen …
14
Why Using Constraints?
n For laying out higher level organization policyn simply a convenience when admin is centralizedn a tool to enforce high-level policies when admin is
decentralized
17
Whether to Allow Multiple Roles to be Activated?
n RBAC96 allows thisn [Baldwin’90] does notn Observations:
n one can define new role to achieve the effect of activating multiple roles
n dynamic constraints are implicit when only one role can be activated in a session
18
What is a Role?
n A set of usersn A set of permissions (named protection
domains)n A set of users and permissionsn Also affects how to interpret role hierarchiesn Maybe it is useful to have both roles and
groups?
19
Roles vs. Groups
n What are the differences?n Answer 1: groups are sets of users, and roles are
sets of users as well as permissionsn doesn’t seem to be true.
n Answer 2: one can activate and deactivate roles, but cannot deactivate groupsn seems unimportant unless there is negative
authorizationn Answer 3: one can enumerate permissions that a
role hasn seems an implementation issue
20
Everything as an attribute?
n Some attributes are more intrinsic about properties of a user
n Some attributes are more intrinsic about job functionalities
21
The NIST Standard
n Proposed NIST Standard for Role-Based Access Control. David F. Ferraiolo, Ravi S. Sandhu, Serban I. Gavrila, D. Richard Kuhn, and Ramaswamy Chandramouli. TISSEC, August 2001.
n ANSI Standard
22
Overview of the NIST Standard for RBAC
Dynamic Separation of Duties
Core RBAC
Hierarchical RBAC
Static Separation of Duties
23
Core RBAC (1)
n USERSn ROLESn OBSn OPSn PRMS = 2(OPS×OBS)
n Op : (p: PRMS) → 2OPS
n Ob : (p: PRMS) → 2OBS
24
Core RBAC (2)
n UA ⊆ USERS × ROLESn assigned_users : (r :Roles) → 2USERS
n PA ⊆ PRMS × ROLESn assigned_permissions : (r :Roles) → 2PRMS
25
Core RBAC (3)
n SESSIONSn session_users : (s :SESSIONS) →USERS
n user_sessions : (u :USERS) → 2SESSIONS
n session_roles : (s :SESSIONS) → 2ROLES
n avail_session_perms :(s :SESSIONS) → 2PRMS
26
Hierarchical RBAC: Generalized Role Hierarchies
n RH ⊆ ROLES × ROLESn user inheritance & permission inheritancen we say r1 inherits r2 if r1 ≥ r2
n authorized_users : (r :Roles) → 2USERS
n authorized_permissions : (r :Roles) → 2PRMS
27
Hierarchical RBAC:Limited Role Hierarchies
n Role Hierarchies with the limitation that each role has at most one immediate seniorn Role hierarchies form a forest
28
Constrained RBAC: Motivations
n Example of SoDn The following duties shall be performed by
different individuals:1. Check request reviewer2. Check preparer3. Check issuer4. Check deliverer5. Ledger reviewer
29
Constrained RBAC:Static SoD
n SSD ⊆ (2ROLES×N) is a collection of pairs (rs, n)n rs: a role setn n: n ≥2 is a natural number
n For each (rs, n), no user is authorized for n or more roles in rs
30
SoD with Role Hierarchies
n Two roles can be mutually exclusive only if neither one inherits the other
n If two roles are mutually exclusive, no role can inherit from both
n If two roles are mutually exclusive, there can be no “root” or “super user”.
31
Constrained RBAC:Dynamic SoD
n DSD ⊆ (2ROLES×N) is a collection of pairs (rs, n)n rs: a role setn n: n ≥2 is a natural number
n For each (rs, n), no user is allowed to activate n or more roles in rs in one session
32
Functional Specifications
n Administrative functionsn Supporting system functionsn Review functions