Administrative Scope and Role-Based Administration

Jason CramptonInformation Security Group

Royal Holloway, University of London

Outline of talk

• Introduction• Administrative scope• The admin-authority relation• Hierarchy operations• Assignment operations• RHA4 and ARBAC97 – a comparison• Administration of complex RBAC models• Conclusion

Access control

• What is it?– Mechanism that ensures only authorized users

have access to computer resources

• Why do we need it?– To limit access to sensitive information

• How does it work?– Authorization information associates users with

resources and access rights

Access control

• Assume user has been authenticated and associated with security identifier (SID)

• User requests access to computer resource with (object) identifier (OID)– Access control mechanism queries authorization

information to determine whether user has permission to access object

– SID and OID are parameters of query

Protection matrix model

• Authorization information stored in a matrix M indexed by subjects and objects– Matrix entry M[s, o] contains access rights that user s is

authorized to use for object o

• Requests modelled as triples (s, o, a)• User request (s, o, a) is permitted if a 2 M[s, o] • Theoretical basis of access control structures such as

access control lists

Administration

• Notion of configuration (or state) of access control system– Introduced by Bell-LaPadula– Static and dynamic components of configuration

• Administration is generic term for changing dynamic components of system

• Without administrative model authorization information does not change

Administration

• Dynamic components in protection matrix model include M, S and O

• Set of access rights A is static

• Administration in protection matrix model performed by commands that add or delete users, objects and matrix entries

• Set of commands is static

Administrationtransfer(a sub, s sub, o obj, t sub)

if owns 2 M[a, o] and r 2 M[s, o] thendelete r from M[s, o]

enter r in M[t, o]

M o

a owns

t

s r

M o

a owns

t r

s

The safety problem

• Modern systems require both administrative flexibility and security guarantees …

• …but permitting (simple) changes to the configuration (of simple models) makes security analysis hard– Harrison, Ruzzo & Ullman (1976, 1978)– Lipton & Snyder (1978)– and many more…

Role-based access control

• Access control model based on the idea of a role– A role is a generalization of a user group

– Role acts as a “bridge” between users and access rights

– Assumption is that number of roles is significantly less than number of users and access rights

• Designed to simplify authorization information– A protection matrix with 00s of users and 0000s of objects

has 000000s of entries

– Studies estimate number of roles to be 4—5% of user population

Role-based access control

• Partially ordered set of roles (R, 6) modelling a role hierarchy– Roles are ordered to reflect enterprise hierarchy

• Set of users U

• Set of permissions P

• User-role assignment UA µ U £ R

• Permission-role assignment PA µ P £ R

Role hierarchies

• Reflect enterprise structure– Support specification of separation duty

constraints

• Used to further reduce the number of user- and permission-role assignments– If (u, r) 2 UA then u is (implicitly) assigned to all

roles s 6 r– If (p, r) 2 PA then p is (implicitly) assigned to all

roles s > r

A typical role hierarchy• If Jason is assigned to

PL1 then he can also activate all roles less senior than PL1

• If permission p is assigned to QE1 then it can also be used by any role more senior than QE1

• Jason can use p

Role-based administration

• Dynamic components of RBAC– (R,6), UA, PA

• Administrative operations– Add or delete edge in role hierarchy (6)– Add or delete role (R)– Add or delete user-role assignment (UA)– Add or delete permission-role assignment (PA)

Administrative scope

• For all r 2 R, define " r = {s R : s > r}r = {s R : s 6 r}

• For all r R, the administrative scope of r, denoted S(r), is defined to be

{s 6 r : s n r µ r}

• The strict administrative scope of r is defined to be S(r) n {r} and denoted S+(r)

So what is administrative scope?

• A set of roles such that any changes to those roles are only “felt” locally

• If r 2 S(a) then all roles greater than or equal to r are in some sense contained by a

• Administrative scope of a role a is the natural unit of administration – the set of roles that a can change

The administrative scope of PL1

• " Emp

• " PL1

• " Emp n " PL1

• # PL1

• " Emp n " PL1 * # PL1

• Emp S(PL1)

The administrative scope of PL1

• " PE1

• " PL1

• " PE1 n " PL1

• # PL1

• " PE1 n " PL1 µ # PL1• PE1 2 S(PL1)• S(PL1)

Administrative scope is dynamic

• Add role X with parent DIR and child QE1

• S(PL1) = {PE1, PL1}

Administrative scope is dynamic

• Add role Y with parent PE1

• S(PL1) = {PE1, PL1, Y}

The RHA administrative models

• A family of administrative models built around concept of administrative scope

• Designed to interoperate with the RBAC96 family of models

• Designed to control updates to the role hierarchy (RHA = role hierarchy administration)

Role-based hierarchy operations

• AddEdge(a, c, p) – Role a adds an edge between child role c and parent role p

• DeleteEdge(a, c, p) – Role a deletes an edge between c and p

• AddRole(a, r, C, P)– Role a adds a role r with child roles C and parent roles P

• DeleteRole(a, r)– Role a deletes role r

Hierarchy operations in RHA1

• AddEdge(a, c, p) succeeds if c, p S(a)• DeleteEdge(a, c, p) succeeds if c, p S(a)• AddRole(a, r, C, P) succeeds if C µ S+(a)

and P µ S(a) • DeleteRole(a, r) succeeds if r 2 S+(a)

Examples – Adding edges

• PL1 cannot add this edge

• DIR can add this edge• This edge cannot be

added in ARBAC97 (by any role)

Examples – Adding roles

• PL1 cannot add this role• DIR can add this role• This role cannot be

added in ARBAC97• PL1 can add this role• This role cannot be

added in ARBAC97

RHA4

• In RHA1 junior roles can have administrative capabilities

• RHA4 is used to provide fine-grained control over which roles have administrative capabilities

• RHA4 defines the relation admin-authority µ R £ R– admin-authority is used to define administrative roles

– RHA4 provides for updates to the admin-authority relation

The extended role hierarchy

• (r, a) is an edge in the extended hierarchy if– (r, a) is an edge in the role hierarchy– (a, r) admin-authority

• Edges in the extended hierarchy do not imply permission inheritance or the ability to activate junior roles– Administrative authority does not imply

authorization

The extended role hierarchy

• admin-authority– (DSO, DIR)

– (DSO, PSO1)

– (PSO1, PL1)

• A user assigned to PSO1 cannot activate PL1 or more junior roles

Administrative scope in RHA4

• If (a, r) 2 admin-authority then– a is an administrative role and a controls r– C(a) denotes the set of roles controlled by a

• Administrative scope of a is S(a) = {s 2 #C(a) : s n C(a) µ #C(a)}

• Strict administrative scope of a isS+(a) = S(a) n C(a)

Administrative scope in RHA4

• C(PSO1) = {PL1}• S(PSO1) = S(PL1)

• Note that RHA1 is a sub-model of RHA4 – (r, r) 2 admin-authority

for all r

Hierarchy operations in RHA4

• AddEdge DeleteEdge AddRole and DeleteRole as for RHA1

• AddAdminAuth(a, b, r) succeeds if b 2 S(a) and r 2 S+(a)

• DeleteAdminAuth(a, b, r) succeeds if b 2 S(a) and r 2 S+(a)

Extending RHA4

• We extend RHA4 to a complete administrative model for RBAC96– AssignUser(a, u, r) succeeds if r 2 S(a)– RevokeUser(a, u, r) succeeds if r 2 S(a)– AssignPermission(a, p, r) succeeds if

r 2 S(a)– RevokePermission(a, p, r) succeeds if

r 2 S(a)

Assignment constraints

• ARBAC97 defines the relations can-assign and can-assignp– (a, c, G) 2 can-assign means that role a can

assign any user that satisfies the constraint c to any role in the range G

• We define a set of prerequisite roles for each role r– AssignUser(a, u, r) succeeds if u is assigned to

each of r’s prerequisite roles and r 2 S(a)

ARBAC97

• Administrative model developed by Sandhu et al (1997—1999) for use with RBAC96

• Three sub-models– URA97 for user-role assignment operations– PRA97 for permission-role assignment operations– RRA97 for role hierarchy operations

Encapsulated ranges

• Basic unit of adminis-tration in ARBAC97

• Sub-hierarchy with a unique maximal and minimal element

• Existence and preservation of encapsulated ranges is a requirement of ARBAC97

RHA4 and ARBAC97 – Similarities

• Designed with RBAC96 in mind

• Designed to provide decentralized administration

• Use of structural properties of role hierarchy to determine validity of administrative operations

RHA4 v ARBAC97 – Completeness

• ARBAC97 only permits updates to RBAC96 relations not ARBAC97 relations– can-modify, can-assign, can-revoke, can-assignp, can-revokep are all static ARBAC97 relations

– This disallows certain hierarchy operations

• In the RHA4 model every RBAC96 and RHA4 relation is dynamic and can be modified

RHA4 v ARBAC97 – Coherence

• ARBAC97– URA97 and PRA97 developed before RRA97– Effect of hierarchy operations on URA97 and

PRA97 relations is not always well defined

• Our approach deals with the difficult issue (hierarchy administration) first– All administrative operations are defined in terms

of administrative scope

RHA4 v ARBAC97 – Applicability

• ARBAC97 can only be used for hierarchies that contain encapsulated ranges– Many role hierarchies do not contain any

encapsulated ranges– We proved that if (x, y) = {z 2 R: x < z < y} is an

encapsulated range then (x, y) µ S+(y)

• RHA4 can be used for any hierarchy

RHA4 v ARBAC97 – Applicability

• ARBAC97 requires that encapsulated ranges are preserved by hierarchy operations– Many operations are prevented

• Administrative scope is dynamic– No operations are prevented

RHA4 v ARBAC97 – Applicability

• Limit inheritance of senior roles– Important if senior roles should

not inherit all permissions

– This hierarchy contains no encapsulated ranges

– Cannot use ARBAC97

• Can use RHA4

– S(PSO1) = {E1, PE1, QE1, PL1}

RHA4 v ARBAC97 – Simplicity

• In ARBAC97 AddRole(a, c, p) succeeds if there exists (b, (w, z)) 2 can-modify such that – a 6 b, w 6 c 6 p 6 z – immediate range of c = immediate range of p– Doesn’t “break” any encapsulated ranges

• In RHA4 AddRole(a, c, p) succeeds if

– c and p belong to S(a)

RHA4 v ARBAC97 – Bootstrapping

• In ARBAC97 hierarchy operations are determined by the can-modify relation– However, the can-modify relation is defined by

encapsulated ranges in the role hierarchy

– Which comes first – the relation or the hierarchy?

• In RHA4 the definition of a single administrative role a with (a, a) 2 admin-authority is a necessary and sufficient pre-condition for the construction of a role hierarchy

Side effects of hierarchy operations

• Deleting an edge from the hierarchy may require the addition of edges to preserve the hierarchy and administrative scope

• Deleting a role may require the amendment of the admin-authority relation to preserve administrative scope

• Adding edges and roles may introduce redundancy into the hierarchy or the admin-authority relation

Side effects

More complex RBAC models

• ERBAC96 (Sandhu 1998)– Defines two separate hierarchies separating role

activation and permission usage– Provides additional separation of duty features

• (G)TRBAC (Bertino et al 2001—)– Introduces temporal dimension to RBAC– Defines a number of different hierarchies

• Role-based trust management (Li et al 2002—)

ERBAC96

• Two partial orders defined on R

• 6a defines an activation hierarchy

– r1 6a r2 implies that any user assigned to r2 can activate r1

• 6u defines a usage hierarchy

– r1 6u r2 implies that any permission assigned to r1 is available to r2

• r1 6u r2 implies that r1 6a r2

ERBAC96

• PL1 does not inherit any permissions assigned to PE1, QE1, or E1

• Any user assigned to PL1 can activate any of PE1, QE1, or E1

• Can define dynamic separation of duty constraint for PE1 and QE1– Not possible in RBAC96

RHA4 for multiple hierarchies

• RHA4 is ideally suited for administration of multiple hierarchies – It can be used for fragmented hierarchies

• Let R be a set of roles and let 61, 62, …, 6k be partial orders defined on R

RHA4 for multiple hierarchies

• DeleteRole and AddRole change the underlying set R– Each operation takes an administrative role and a

role as a parameter– Compare AddRole for single hierarchies which

includes the set of children and parents of the new role as parameters

RHA4 for multiple hierarchies

• DeleteEdge and AddEdge change a partial ordering– DeleteEdge(a, c, p, i) deletes the edge (c, p)

from the ith hierarchy– AddEdge(a, c, p, i) adds the edge (c, p) to the ith

hierarchy

ERBAC96 – Hierarchy evolution

Role-based trust management• Policy statements express relationships

between principals (users) and roles– A.r à B.s– “If B says u is assigned to s then A says u is

assigned to r”– Policy statements converted into logic program

clauses

says(A, is-assigned(X, r)) :- says(B, is-assigned(X, s))

Role-based trust management

• Changes in state (administration) are limited by restriction rules– A policy statement about r can be added provided r is not

growth-restricted

– A policy statement about r can be deleted provided r is not shrink-restricted

• Alternatively we can consider restriction rules that limit the roles that can add policy statements– This is the approach of ARBAC97 and RHA4

Role-based trust management

• Has been applied to URA97 component of ARBAC97

• system .r à system .a.r Å system .rc

– system says u is assigned to r if a user in administrative role system .a says u is assigned to r and u is already assigned to rc

– This is essentially the same as saying the assignment of u to r can be made by a provided (a, rc, r) 2 can-assign

Role-based trust management

• Can we use administrative scope with role-based trust management?

• system .r à system .a.r– If a says u is assigned to r then system says u is

assigned to r

• The restriction rules would simply embody the idea of administrative scope– A policy statement a.r à u can be added provided r

2 S(a)

Conclusions

• Administrative scope is a powerful primitive for role-based administration– Leads to a number of useful models– Is widely applicable and can be used to build

administrative frameworks for more complex RBAC models

– Is sufficiently flexible to interoperate with different role-based models

Current and future work• Current

– Completion of administrative models for ERBAC96 and GTRBAC

– Administration of separation of duty constraints– Implementation of RBAC API including RHA4

functionality• Future

– More thorough investigation into the use of administrative scope in role-based trust management

– Can we use administrative scope in other access control contexts where hierarchical structures (such as file systems) need to be managed?

References• J. Crampton and G. Loizou. Administrative scope: A foundation for role-

based administrative models. ACM Transactions on Information and System Security, 6(2), 201—231, 2002.

• N. Li, J.C. Mitchell and W.H. Winsborough. Design of a role-based trust-management framework. In Proceedings of the 2002 IEEE Symposium on Security and Privacy, 114—130, 2002.

• N. Li and M.V. Tripunitara. Security analysis in role-based access control. In Proceedings of the Ninth ACM Symposium on Access Control Models and Technologies, 126—135, 2004.

• R. Sandhu. Role activation hierarchies. In Proceedings of Third ACM Workshop on Role-Based Access Control 33—40, 1998.

• R. Sandhu, V. Bhamidipati and Q. Munawer. The ARBAC97 model for role-based administration of roles. ACM Transactions on Information and System Security, 1(2), 105—135, 1999.