Administrative Scope and Role-Based Administration Jason Crampton Information Security Group Royal Holloway, University of London

Outline of talk Introduction Administrative scope The admin-authority relation Hierarchy operations Assignment operations RHA 4 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

Administration transfer(a sub, s sub, o obj, t sub) if owns 2 M[a, o] and r 2 M[s, o] then delete r from M[s, o] enter r in M[t, o] Mo aowns t sr Mo a tr 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 s 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 RHA 1 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

RHA 4 In RHA 1 junior roles can have administrative capabilities RHA 4 is used to provide fine-grained control over which roles have administrative capabilities RHA 4 defines the relation admin-authority µ R £ R –admin-authority is used to define administrative roles –RHA 4 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 RHA 4 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 is S + (a) = S(a) n C(a)

Administrative scope in RHA 4 C(PSO1) = {PL1} S(PSO1) = S(PL1) Note that RHA 1 is a sub- model of RHA 4 –(r, r) 2 admin-authority for all r

Hierarchy operations in RHA 4 AddEdge DeleteEdge AddRole and DeleteRole as for RHA 1 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 RHA 4 We extend RHA 4 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

RHA 4 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

RHA 4 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 RHA 4 model every RBAC96 and RHA 4 relation is dynamic and can be modified

RHA 4 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

RHA 4 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) RHA 4 can be used for any hierarchy

RHA 4 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

RHA 4 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 RHA 4 –S(PSO1) = {E1, PE1, QE1, PL1}

RHA 4 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 RHA 4 AddRole (a, c, p) succeeds if –c and p belong to S(a)

RHA 4 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 RHA 4 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 6 a defines an activation hierarchy –r 1 6 a r 2 implies that any user assigned to r 2 can activate r 1 6 u defines a usage hierarchy –r 1 6 u r 2 implies that any permission assigned to r 1 is available to r 2 r 1 6 u r 2 implies that r 1 6 a r 2

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

RHA 4 for multiple hierarchies RHA 4 is ideally suited for administration of multiple hierarchies –It can be used for fragmented hierarchies Let R be a set of roles and let 6 1, 6 2, …, 6 k be partial orders defined on R

RHA 4 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

RHA 4 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 RHA 4

Role-based trust management Has been applied to URA97 component of ARBAC97 system.r à system.a.r Å system.r c –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 r c –This is essentially the same as saying the assignment of u to r can be made by a provided (a, r c, 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 RHA 4 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, 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, 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, R. Sandhu. Role activation hierarchies. In Proceedings of Third ACM Workshop on Role-Based Access Control 33—40, 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.