Presented by

Dustin Burke

Senior in Computer Science (4th Year) Specializing in Graphics and Visualization Graduating in May, 2008 Lived in Atlanta area my entire life Travel for roller coasters

What are roles and why are they important? Model Elements Mappings & Relations Static and Dynamic Properties Role Hierarchies Implications

Role - is an organizational identity that defines a set of allowable actions for an authorized user RBAC mechanisms rely on role constructs to mediate a users access to computational resources Role hierarchy overall set of capability relationships which can be represented as a directed acyclic graph

Properties of this model fall into either a static or a dynamic category

Static deals mainly with constraints on role membership Dynamic deals with constraints on role activation

User people who use the system Subject active entities of the system operating within roles on behalf of users Role named duties within an organization Operation set of access modes permitted Object passive entities protected from unauthorized use Permission set of ordered operation/object pairs

Ternary relationship between Role, Operation, and Object is broken down Conforms with privileges found in present day information systems

Can represent a broad range of access controls

Basic read/write/execute rights on a file Administrative rights for OS commands

Depends on context

More specific mappings refine the general relationships in the previous diagrams
authorized-roles[u]
Roles authorized for user u

authorized-permissions[i]
Permissions authorized for role i

active-user[x]
User u associated with subject x

active-roles[x]
Roles in which a subject x is active

Properties of the model that do not involve either the Subject component or mappings from Subject to other basic components Apply early, at role authorization, and through role activation Very strong Include cardinality, separation of duty, and operational separation of duty

membership-limit[i]
Maximum number of users that can be authorized to a role

authorized-members[i]
Number of users authorized a given role

Responsibilities split to prevent collusion Group of roles are mutually exclusive of one another with regard to authorization User may only be authorized to one
A B C D

Not in SSD

Member of SSD

Business tasks are composed of multiple operations No single user can be authorized one or more roles having permissions involved in an SOSD
User 01010 D A B C <A,B> not in SOSD <B,D> not in SOSD <A,C> in SOSD

Complement static properties Weaker than static

Applied at role activation and not checked at authentication Also offers degrees of flexibility

Often used in conjunction with static properties Include role activation, cardinality, separation of duty, and operational separation of duty

exec: Subject Operation Object

True iff subject can perform operation on object

active-membership-limit[i] active-members[i] Permitted action subject can perform an operation on an object iff the subject is acting within an active role authorized that permission

A subject cannot be active in a role it does not have authorization for Active roles must be a subset of authorized roles

Roles: A, B, C, D, E For Subject z to have A or B in its active roles, they must first be included in its authorized roles

Number of users active in a role can never exceed the dynamic capacity More desirable than static because it is maintained at activation as opposed to authorization For example: a role with capacity of one would ensure consecutive use of capabilities

Very similar to Static Separation of Duty Memory-less property

Has no history of activation kept for user Prevents simultaneous activations by a user but does not safeguard against consecutive activation Not appropriate in some environments

User u requests to be active in A and B while <A,B> is in DSD; rejected User u requests to be active in A; allowed User u requests to be active in B; allowed

Group of permissions may be designated as mutually exclusive with regard to roles activated by a subject As with DSD, memory-less

A role may be defined in terms of one or more other roles

And can include additional characteristics Automatically takes on or inherits the collective characteristics of roles Containment is recursive

Substitution of role instances

Include given role plus set of roles contained by that role Can also be related to role authorization
A user is authorized to perform tasks based on its roles as well as its roles roles and its roles roles roles and its
roles roles roles roles and

Containment is not reflexive but is transitive

Role i is not in the subset of i If j is a subset of i and k is a subset of j, then j is a subset of i

Containing roles accumulate not only the capabilities of contained roles, but constraints and separations of duty relationships Permitted Actions are expanded to include those privileges associated with effective roles

Cardinality Inheritance: a containing role must be assigned a membership limit less than or equal to that of any contained role
Role A Max: ?

B: 15

D: 25

Role A would be given a capacity of the minimum of its contained roles. 7 from C.

C: 7

Separation of duty relationship cannot exist between roles that have a containment relation between them or are contained by another role in common (common heir)
C <A,B> is a member of SSD But since C inherits both A and B, <A,B> is no longer a member of SSD

If one role contains another role that has an SD relationship with a third role, then the containing role also has an SD relationship with the third role
A

If <B,C> is a member of SSD, and A inherits B, then <A,C> is also a member of SSD C

Property
Role Activation Permitted Action Cardinality Separation of Duty Operational Separation of Duty Role Hierarchy Permitted Action on Modified Hierarchies

Static

Dynamic

Cardinality Inheritance Separation of Duty Hierarchy

Separation of Duty Inheritance

Inheritance Properties of Role Hierarchies

W. A. Jansen National Institute of Standards and Technology