The Role Graph Model and Tools for Design of Access Control

1. The Role Graph Model and Tools for Design of Access Control Sylvia Osborn Dept. of Computer Science The University of Western Ontario

2. Outline of Talk • Role Graph Model • Some Basic Tools • Information Flow Analysis • Other things we are working on

3. The Role Graph Model: Three Planes(with Matunda Nyanchama)

4. Role Graph Properties • there is a single MaxRole, • there is a single MinRole, • the graphs are acyclic, • there is a path from MinRole to every role ri, • there is a path from every role ri to MaxRole, • distinguish between direct privileges (not available in any of the role’s juniors) and effective privileges (direct privileges together with all inherited privileges)

5. Role Graph Properties, cont’d • for any two roles ri and rj, if effective(ri)  effective(rj),then there must be a path from ri to rj • by convention we draw the graphs with MaxRole at the top, MinRole at the bottom, and junior roles lower on the page than their seniors. • We also remove transitive edges from the display to make the graph less cluttered.

6. Role Graph Algorithms • We have developed algorithms to: • add a role giving its direct privileges, expected juniors and seniors • add a role giving effective privileges • add/delete a privilege to/from a role • add/delete an edge • All run in time polynomial in size of graph and size of privilege sets. • All algorithms abort if a cycle would be created in the role graph. Otherwise, restore role graph properties. • We have also discussed how to export the design to a relational DBMS, or a Unix system with ACLs.

7. Groups • Other RBAC models do not consider groups. • Groups are organized into a group graph. • Here, edges represent proper subset relationship. • In small applications, each user can be regarded as a group of cardinality 1. • In large applications, do not want individual users. • Group modeling focuses on what users have in common. E.g. can have a group for users with the same qualifications, or for members of a committee, who might have different job titles. • Can force subset relationship by making subgroups.

8. Role design vs. Group design • Role design involves deciding what permissions are necessary or required for a job function, task or service. • Group design - deciding what groups to have - involves focusing on what might be useful sets of users to have, rather than on the details of what they will use or do. • Assigning users to groups involves looking at some qualifications or requirements of each user. • In a corporate environment, role design might be carried out by a system administrator, whereas group assignments might be carried out by HR.

9. Privileges • There can be implications among privileges. • Based on OODB work (by Rabitti, Bertino, Kim and Woelk), can have implications based on (s, o, a) • Subject considerations correspond to roles • Object containment • Access modes (e.g. write does or does not imply read) • Also from schema to instance • Carries over fairly naturally to XML data

10. Static vs. Dynamic aspects • The following are fairly static: • Design/alteration of the role graph • Design/alteration of the group graph • Design of the implication patterns in the privileges plane • Less static would be: • Assignment of users to groups • Assignment of users/groups to roles • Most dynamic: • Role activation/deactivation

11. 2. Desirable Tools • Given a user, what are all the roles they can activate or are assigned to? - have • Given a user, what are all the privileges they can have? - some effort. • Given a privilege, who are all the users who can perform this operation? - harder • Given a role, who are all the users who can activate this role? - have In general, what are the consequences of our model?

12. Prototype Implementation

13. Click on a group or user node:

14. Click on a role:

15. 3. Information Flow Analysis(based on a paper in 2002 ACM SACMAT) • RBAC early on claimed to be more general than DAC and MAC (also known as LBAC) • Work by Sandhu and Munawer showed how to simulate various forms of DAC • Work by Sandhu showed how to simulate MAC • Work by Osborn showed how, given a role graph and security labels, to test if LBAC properties are satisfied. • What was missing was to try to convert from RBAC to LBAC – i.e. to show for a given RBAC system what lattice the role graph might correspond to, which shows what information flows are possible

16. Properties of LBAC models • All objects and subjects have a security label • The security labels form a lattice • Reading and writing are typically the only operations considered • Simple Security Property: subject s can read object o only if label(s)  label(o) • Writing is governed by the Liberal -property or the strict -property • Liberal -property: subject s can write object o only if label(s) ≤ label(o) • Strict -property: subject s can write object o only if label(s) = label(o)

17. Information Flow within a Single Role • The smallest unit of privilege assignment is a role • A user, acting in a role which contains (o1, r) and (o2, w), can cause information to flow from o1 to o2. • Also, any object represents information flow when (o, w) is in a role and (o, r) is in the same or possibly a different role. We also assume information flow from (o, r) to (o, w). (i.e., object o will ultimately have one label.)

18. Example Role Graphwith effective privileges Initial Can-Flow Graph R3 {(a,r),(b,r),(b,w),(c,r),(c,w)} R1 {(a,r),(b,w)} R2 {(a,r),(b,r)}

19. After Collapsing Cycles

20. Considerations for the Algorithm • Trying to get the fairest view of what information flows there can be. • If in every role graph, MaxRole is considered in the algorithm, then the flow graph would degenerate into a single node, since MaxRole has all the privileges. • Really only need to look at roles that can be assigned. • Sandhu’s models have a concept of a session, which captures the notion of which roles are active concurrently. • Can also have constraints preventing two roles from being activated together.

21. Algorithm for each role rkin URA for some user for each privilege (o, a) create a node for (rk, o, a) for each pair in rk of form (oi, r) (oj, w) put edge from (rk, oi, r) to (rk, oj, w) for each object o if nodes ni, nj contain the same object o then insert edges ni to nj and nj to ni for all roles ri, rkpermitted in same session by URA or constraints for all pairs (ri, o1, r) and (rk, o2, w) add edge from (ri, o1, r) to (rk, o2, w) collapse cycles

22. This example from Sandhu With the constraint that L users are assigned LW and LR, etc. Gives this flow:

23. Example yielding a non-lattice This role graph: R1{(c,r),(a,w)} R2{(c,r),(b,w)} R3{(d,r),(a,w)} R4{(d,r),(b,w)} Gives this flow: a b d c

24. Summary of Information Flow Work • If the flow graph is a lattice, we have a solution to mapping an arbitrary RBAC system to an LBAC system with the same information flow. • i.e., we can consider the flow graph to be a candidate security labeling. • If it is not a lattice, what do we do? One possibility is to merge common upper bounds (like a and b in the previous example). • In any case, the flow graph provides useful information.

25. 4. Other things • Role graph administration: • Looking at a decentralized administrative model. • Which is intuitive to people in business. • A model that leaves the underlying role graph and its properties and algorithms intact. • To have administrative roles part of the role graph. • To allow a hierarchy of administrative roles. • To recognize that the “reports-to” graph and the role graph may be different.

27. Administrative Domains • Set of roles with a top role called the domain ID • The administrative domain contains all roles junior to the domain ID except for MinRole • The default domain whose domain ID is MaxRole does contain MinRole. • All operations within a domain must work with privileges already available in the domain ID and must only deal with roles within the domain. This way operations cannot alter surrounding domains. • Privileges are added to a domain ID by an administrator of a surrounding domain.

28. Some properties of Administrative Domains Administrative Domains must not overlap - changes made in one domain would affect another domain.

29. Other Things, cont’d • Propagation of Privileges • We have explored the privileges plane in some detail for propagation of privileges in general, and extended this to security over XML documents. C. Delegation • Currently looking at delegation within the context of the Role Graph Model and our administrative model.

30. Conclusions • Important to have a good reference model so that all the dimensions of a problem can be explored. • Important to realize whether you need a model or a mechanism. Papers can be found at: http://www.csd.uwo.ca/faculty/sylvia/pubs.html