© 2004 ravi sandhu role-based access control prof. ravi sandhu laboratory for information security...

© 2004 Ravi Sandhuwww.list.gmu.edu

Role-Based Access Control

Prof. Ravi SandhuLaboratory for Information Security Technology

George Mason University

www.list.gmu.edu

[email protected]


Access Control Models:A perspective

3


Access Matrix Model (Lampson 1971)

U r w

V

F

Subjects

Objects (and Subjects)

r w

G

r

rights

4


Access Matrix Model

• Separates authentication from authorization• Rights are persistent

These items have come into question in recent times, but that is a topic for another talk.

• Separates model from implementation• Policy versus mechanism

This separation continues to be valuable and will be discussed and refined later in this talk.

5


MAC, DAC and RBAC

• For 25 years (1971-96) access control was divided into• Mandatory Access Control (MAC)

• Discretionary Access Control (DAC)

• Since the early-mid 1990’s Role-Based Access Control (RBAC) has become a dominant force• RBAC subsumes MAC and DAC

• RBAC is not the “final” answer BUT is a critical piece of the “final” answer

6


Mandatory Access Control (MAC)

TS

S

C

U

InformationFlow

Dominance

Lattice ofsecuritylabels

Rights are determined by security labels (Bell-LaPadula 1971)

7


Mandatory Access Control (MAC)

U r w

V

F

Subjects


r w

G

r

security label of F must dominate or equal security label of G

8


Discretionary Access Control (DAC)

• The owner of a resource determines access to that resource• The owner is often the creator of the resource

• Fails to distinguish read from copy• This distinction has re-emerged recently under the

name Dissemination Control (DCON)

9



U r w

V

F

Subjects


r w

G

r

10



U r wown

V

F

Subjects


r wown

G

r

Rights are determined by the owners

11


Beyond DAC and MAC

• Many attempts were made• Domain-Type enforcement (Boebert-Kain 1985)• Clark-Wilson (1987)• Chinese Walls (Brewer-Nash 1989)• Harrison-Ruzzo-Ullman (1976)• Schematic Protection Model (Sandhu 1985)• Typed Access Matrix Model (Sandhu 1992)• …………………

• RBAC solves this problem


Role-Based Access Control:The RBAC96 Model

• Ravi Sandhu, Edward Coyne, Hal Feinstein and Charles Youman, “Role-Based Access Control Models.” IEEE Computer, Volume 29, Number 2, February 1996, pages 38-47.

13


ROLE-BASED ACCESS CONTROL (RBAC)

• A user’s permissions are determined by the user’s roles• rather than identity or clearance• roles can encode arbitrary attributes

• multi-faceted

• ranges from very simple to very sophisticated

14


Central concept of RBAC

ROLES

USER-ROLEASSIGNMENT

PERMISSION-ROLEASSIGNMENT

USERS PERMISSIONS

15


WHAT IS THE POLICY IN RBAC?

• RBAC is a framework to help in articulating policy

• The main point of RBAC is to facilitate security management

16


RBAC SECURITY PRINCIPLES

• least privilege

• separation of duties

• separation of administration and access

• abstract operations

17


RBAC96 IEEE Computer Feb. 1996

• Policy neutral

• can be configured to do MAC• roles simulate clearances (ESORICS 96)

• can be configured to do DAC• roles simulate identity (RBAC98)

18


WHAT IS RBAC?

• multidimensional

• open ended

• ranges from simple to sophisticated

19


RBAC CONUNDRUM

• turn on all roles all the time

• turn on one role only at a time

• turn on a user-specified subset of roles

20


RBAC96 FAMILY OF MODELS

RBAC0BASIC RBAC

RBAC3ROLE HIERARCHIES +

CONSTRAINTS

RBAC1ROLE

HIERARCHIES

RBAC2CONSTRAINTS

21


RBAC0

ROLES

USER-ROLEASSIGNMENT


USERS PERMISSIONS

... SESSIONS

22


PERMISSIONS

• Primitive permissions• read, write, append, execute

• Abstract permissions• credit, debit, inquiry

23


PERMISSIONS

• System permissions• Auditor

• Object permissions• read, write, append, execute, credit, debit, inquiry

24


PERMISSIONS

• Permissions are positive

• No negative permissions or denials• negative permissions and denials can be handled

by constraints

• No duties or obligations• outside scope of access control

25


ROLES AS POLICY

• A role brings together• a collection of users and• a collection of permissions

• These collections will vary over time• A role has significance and meaning beyond the

particular users and permissions brought together at any moment

26


ROLES VERSUS GROUPS

• Groups are often defined as• a collection of users

• A role is• a collection of users and• a collection of permissions

• Some authors define role as • a collection of permissions

27


USERS

• Users are• human beings or• other active agents

• Each individual should be known as exactly one user

28


USER-ROLE ASSIGNMENT

• A user can be a member of many roles

• Each role can have many users as members

29


SESSIONS

• A user can invoke multiple sessions

• In each session a user can invoke any subset of roles that the user is a member of

30


PERMISSION-ROLE ASSIGNMENT

• A permission can be assigned to many roles

• Each role can have many permissions

31


MANAGEMENT OF RBAC

• Option 1:• USER-ROLE-ASSIGNMENT and

PERMISSION-ROLE ASSIGNMENT can be changed only by the chief security officer

• Option 2:• Use RBAC to manage RBAC

32


RBAC1

ROLES

USER-ROLEASSIGNMENT


USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

33


HIERARCHICAL ROLES

Health-Care Provider

Physician

Primary-CarePhysician

SpecialistPhysician

34


HIERARCHICAL ROLES

Engineer

HardwareEngineer

SoftwareEngineer

SupervisingEngineer

35


PRIVATE ROLES

Engineer

HardwareEngineer

SoftwareEngineer

SupervisingEngineer

HardwareEngineer’

SoftwareEngineer’

36


EXAMPLE ROLE HIERARCHY

Employee (E)

Engineering Department (ED)

Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Director (DIR)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1

37



Employee (E)


Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1

38



Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Director (DIR)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1

39



Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1

40


RBAC3

ROLES

USER-ROLEASSIGNMENT

PERMISSIONS-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

CONSTRAINTS

41


CONSTRAINTS

Mutually Exclusive Roles• Static Exclusion: The same individual can never

hold both roles• Dynamic Exclusion: The same individual can

never hold both roles in the same context

42


CONSTRAINTS

• Mutually Exclusive Permissions• Static Exclusion: The same role should never be

assigned both permissions• Dynamic Exclusion: The same role can never hold

both permissions in the same context

43


CONSTRAINTS

• Cardinality Constraints on User-Role Assignment• At most k users can belong to the role• At least k users must belong to the role• Exactly k users must belong to the role

44


CONSTRAINTS

• Cardinality Constraints on Permissions-Role Assignment• At most k roles can get the permission• At least k roles must get the permission• Exactly k roles must get the permission


The NIST-ANSI and (hopefully) soon-to-be ISO RBAC Standard Model

• David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, D. Richard Kuhn and Ramaswamy Chandramouli. “Proposed NIST Standard for Role-Based Access Control.” ACM Transactions on Information and System Security, Volume 4, Number 3, August 2001, pages 224-274.

46


The NIST-ANSI-ISO RBAC Model

• Adds much needed detail and consensus agreement to the RBAC96 model and other contemporary models

• Focuses on areas where consensus agreement exists and commercial implementations have been demonstrated• Leaves many important areas for future work

• Eventual goal is much more ambitious• Test suite for conformance testing

47


RBAC96 FAMILY OF MODELS

RBAC0BASIC RBAC

RBAC3ROLE HIERARCHIES +

CONSTRAINTS

RBAC1ROLE

HIERARCHIES

RBAC2CONSTRAINTS

48



49



• Additional details• Administrative Functions• Supporting System Functions• Review Functions

50


Core RBAC

51


Core RBAC: Administrative Functions

• AddUser• DeleteUser• AddRole• DeleteRole• AssignUser• DeassignUser• Grant-Permission• Revoke-Permission

52


Core RBAC: Supporting System Functions

• CreateSession

• AddActiveRole

• DropActiveRole

• CheckAccess

53


Core RBAC: Review Functions

• Required• AssignedUsers• AssignedRoles

• Optional• RolePermissions• UserPermissions• SessionRoles• SessionPermissions• RoleOperationsOnObject• SessionOperationsOnObject

Role-permission review is optional

Role-user review is required

54


Hierarchical RBAC

55


Limited Hierarchies

56


Limited Hierarchies

57


General Hierarchies

58


Inheritance versus Activation Hierarchy

59


Inheritance versus Activation Hierarchy

• Inheritance hierarchy• Activating Director Role also activates all junior roles (by

inheritance of permissions)• Violates least privilege

• Activation hierarchy• Activating Director Role does not activate junior roles

(there is no inheritance of permissions)• Junior roles must be explicitly activated• Preserves least privilege but is less automated

60


Constrained RBAC: Static Separation of Duties

61


Constrained RBAC: Dynamic Separation of Duties


MAC and DAC in RBAC

• Sylvia Osborn, Ravi Sandhu and Qamar Munawer. “Configuring Role-Based Access Control to Enforce Mandatory and Discretionary Access Control Policies.” ACM Transactions on Information and System Security, Volume 3, Number 2, May 2000, pages 85-106.

63


MAC

H

L

M1 M2

Read Write- +

+ -

64


MAC in RBAC96

HR

LR

M1R M2R

LW

HW

M1W M2W

Read Write-

+

65


MAC in RBAC96• user xR, user has clearance x• user LW, independent of clearance• Need constraints

• session xR iff session xW• in a session exactly one read role must be activated, and this

cannot be changed• read can be assigned only to xR roles• write can be assigned only to xW roles• (O,read) assigned to xR iff• (O,write) assigned to xW

66


DAC in RBAC96

• Construction is more complex

• Requires multiple roles for every object

• Revocation• Grant-dependent revocation is harder to handle• Grant-independent revocation is easier to handle

67


MAC and DAC in the NIST-ANSI-ISO Model

• RBAC96 constructions use cardinality constraints in addition to Static and Dynamic separation of duties

• These constructions are not applicable to NIST-ANSI-ISO RBAC model

• Can NIST-ANSI-ISO RBAC model do MAC and DAC?• With extensions: yes

• Without extensions: probably not


Administrative RBAC: ARBAC97

• Ravi Sandhu, Venkata Bhamidipati and Qamar Munawer. “The ARBAC97 Model for Role-Based Administration of Roles.” ACM Transactions on Information and System Security, Volume 2, Number 1, February 1999, pages 105-135.



Employee (E)


Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Director (DIR)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1


EXAMPLE ADMINISTRATIVE ROLE HIERARCHY

Senior Security Officer (SSO)

Department Security Officer (DSO)

Project SecurityOfficer 1 (PSO1)

Project SecurityOfficer 2 (PSO2)

71


URA97 GRANT MODEL: can-assign

ARole Prereq Role Role Range

PSO1 ED [E1,PL1)

PSO2 ED [E2,PL2)

DSO ED (ED,DIR)

SSO E [ED,ED]

SSO ED (ED,DIR]

72


URA97 GRANT MODEL

• “redundant” assignments to senior and junior roles• are allowed• are useful

73


URA97 REVOKE MODEL

WEAK REVOCATION• revokes explicit membership in a role• independent of who did the assignment

74


URA97 REVOKE MODEL

STRONG REVOCATION• revokes explicit membership in a role and its seniors• authorized only if corresponding weak revokes are

authorized• alternatives

– all-or-nothing

– revoke within range

75


URA97 REVOKE MODEL : can-revoke

ARole Role Range

PSO1 [E1,PL1)

PSO2 [E2,PL2)

DSO (ED,DIR)

SSO [ED,DIR]

76


PERMISSION-ROLE ASSIGNMENT

• dual of user-role assignment• can-assign-permission• can-revoke-permission• weak revoke• strong revoke (propagates down)

77


PERMISSION-ROLE ASSIGNMENT CAN-ASSIGN-PERMISSION

ARole Prereq Cond Role Range

PSO1 PL1 [E1,PL1)

PSO2 PL2 [E2,PL2)

DSO E1 E2 [ED,ED]

SSO PL1 PL2 [ED,ED]

SSO ED [E,E]

78


PERMISSION-ROLE ASSIGNMENT CAN-REVOKE-PERMISSION

ARole Role Range

PSO1 [E1,PL1]

PSO2 [E2,PL2]

DSO (ED,DIR)

SSO [ED,DIR]


OM-AM and RBAC

80


THE OM-AM WAY

Objectives

Model

Architecture

Mechanism

What?

How?

Assurance

81


LAYERS AND LAYERS

• Multics rings• Layered abstractions• Waterfall model• Network protocol stacks• Napolean layers• RoFi layers• OM-AM• etcetera

82


OM-AM AND MANDATORY ACCESS CONTROL (MAC)

What?

How?

No information leakage

Lattices (Bell-LaPadula)

Security kernel

Security labels

Assurance

83


OM-AM AND DISCRETIONARY ACCESS CONTROL (DAC)

What?

How?

Owner-based discretion

numerous

numerous

ACLs, Capabilities, etc

Assurance

84


OM-AM AND ROLE-BASED ACCESS CONTROL (RBAC)

What?

How?

Objective neutral

RBAC96, ARBAC97, etc.

user-pull, server-pull, etc.

certificates, tickets, PACs, etc.

Assurance

85


Server-Pull Architecture

Client Server

User-roleAuthorization

Server

86


User-Pull Architecture

Client Server


Server

87


Proxy-Based Architecture

Client ServerProxyServer


Server

88


RBAC Mechanisms

• RBAC can be implemented using• Secure cookies: user-pull architecture• X.509 certificates: user-pull or server-pull

architectures


Other RBAC Research and Results

90


RBAC Research (dates are approximate)

• The early NIST model: Ferraiolo et al 1992 onwards• Role-Graph Model: Osborn et al 1994 onwards• OASIS model and architecture: Moody et al 1994 onwards• Trust Management: Herzberg, Li, Winsborough, et al 1996 onwards• Temporal RBAC: Bertino et al 1998 onwards• Constraint languages: Ahn and Sandhu, 2000• Delegation in RBAC: Barka, Sandhu, Ahn et al 2000 onwards• RBAC and workflow systems: Atluri, Sandhu, Ahn, Park et al 1998 onwards• RBAC administration: Kern, Sandhu, Oh, Moffett et al 1998 onwards• RBAC engineering: Thomsen, Kern, Epstein, Sandhu et al 2000 onwards• Context-aware RBAC: Covington et al, 2000 onwards• Rule-based RBAC: Al-Khatani and Sandhu, 2002 onwards• ………………….


Ongoing and Future Work in RBAC

92


Research Challenges

• Automated RBAC• RBAC engineering• Formal models for RBAC• Analysis of RBAC policies• Integration with attribute-based access control• RBAC in pervasive and ad hoc environments• Cross-domain RBAC• ………….

© 2004 ravi sandhu role-based access control prof. ravi sandhu laboratory for information security...

Documents

ravi sandhu laboratory

rbac96 model ravi sandhu

scope of access control

sophisticated slide

inquiry slide

sessions slide

perspective slide

problem slide