Administrative Scope and RoleBased Administration

1
Administrative Scope and Role-Based
Administration

• Jason Crampton
• Information Security Group
• Royal Holloway, University of London

2
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

3
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

4
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

5
Protection matrix model

• Authorization information stored in a matrix M
  indexed by subjects and objects
• Matrix entry Ms, 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 Ms,
  o
• Theoretical basis of access control structures
  such as access control lists

6
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

7
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

8
Administration

• transfer(a sub, s sub, o obj, t sub)
• if owns 2 Ma, o and r 2 Ms, o then
• delete r from Ms, o
• enter r in Mt, o

9
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

10
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 45 of
  user population

11
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

12
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 gt r

13
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

14
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)

15
Administrative scope

• For all r 2 R, define
• " r s ? R s gt 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)

16
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

17
The administrative scope of PL1

• " Emp
• " PL1
• " Emp n " PL1
• PL1
• " Emp n " PL1 PL1
• Emp ? S(PL1)

18
The administrative scope of PL1

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

19
Administrative scope is dynamic

• Add role X with parent DIR and child QE1
• S(PL1) PE1, PL1

20
Administrative scope is dynamic

• Add role Y with parent PE1
• S(PL1) PE1, PL1, Y

21
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)

22
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

23
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)

24
Examples Adding edges

• PL1 cannot add this edge
• DIR can add this edge
• This edge cannot be added in ARBAC97 (by any role)

25
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

26
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

27
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

28
The extended role hierarchy

• admin-authority
• (DSO, DIR)
• (DSO, PSO1)
• (PSO1, PL1)
• A user assigned to PSO1 cannot activate PL1 or
  more junior roles

29
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 is
• S(a) S(a) n C(a)

30
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

31
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)

32
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)

33
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 rs prerequisite roles and r 2 S(a)

34
ARBAC97

• Administrative model developed by Sandhu et al
  (19971999) for use with RBAC96
• Three sub-models
• URA97 for user-role assignment operations
• PRA97 for permission-role assignment operations
• RRA97 for role hierarchy operations

35
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

36
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

37
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

38
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

39
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 lt z lt y is
  an encapsulated range then (x, y) µ S(y)
• RHA4 can be used for any hierarchy

40
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

41
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

42
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
• Doesnt break any encapsulated ranges
• In RHA4 AddRole(a, c, p) succeeds if
• c and p belong to S(a)

43
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

44
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

45
Side effects
46
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)

47
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

48
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

49
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

50
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

51
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

52
ERBAC96 Hierarchy evolution
53
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))

54
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

55
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

56
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)

57
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

58
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?

59
References

• J. Crampton and G. Loizou. Administrative scope
  A foundation for role-based administrative
  models. ACM Transactions on Information and
  System Security, 6(2), 201231, 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, 114130, 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, 126135, 2004.
• R. Sandhu. Role activation hierarchies. In
  Proceedings of Third ACM Workshop on Role-Based
  Access Control 3340, 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), 105135, 1999.