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

2. April 27, 20052 Outline of Talk 1.Role Graph Model 2.Some Basic Tools 3.Information Flow Analysis 4.Other things we are working on

3. April 27, 20053 1.The Role Graph Model: Three Planes (with Matunda Nyanchama)

4. April 27, 20054 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 r i, there is a path from every role r i 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. April 27, 20055 Role Graph Properties, cont’d for any two roles r i and r j, if effective(r i )  effective(r j ), then there must be a path from r i to r j 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. April 27, 20056 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. April 27, 20057 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. April 27, 20058 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. April 27, 20059 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. April 27, 200510 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. April 27, 200511 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. April 27, 200512 Prototype Implementation

13. April 27, 200513 Click on a group or user node:

14. April 27, 200514 Click on a role:

15. April 27, 200515 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. April 27, 200516 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. April 27, 200517 Information Flow within a Single Role The smallest unit of privilege assignment is a role A user, acting in a role which contains (o 1, r) and (o 2, w), can cause information to flow from o 1 to o 2. 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. April 27, 200518 Initial Can-Flow Graph Example Role Graph with effective privileges R3 {(a,r),(b,r),(b,w),(c,r),(c,w)} R1 {(a,r),(b,w)} R2 {(a,r),(b,r)}

19. April 27, 200519 After Collapsing Cycles

20. April 27, 200520 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. April 27, 200521 Algorithm for each role r k in URA for some user for each privilege (o, a) create a node for (r k, o, a) for each pair in r k of form (o i, r) (o j, w) put edge from (r k, o i, r) to (r k, o j, w) for each object o if nodes n i, n j contain the same object o then insert edges n i to n j and n j to n i for all roles r i, r k permitted in same session by URA or constraints for all pairs (r i, o 1, r) and (r k, o 2, w) add edge from (r i, o 1, r) to (r k, o 2, w) collapse cycles

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

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

24. April 27, 200524 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. April 27, 200525 4. Other things A.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.

26. April 27, 200526

27. April 27, 200527 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. April 27, 200528 Some properties of Administrative Domains Administrative Domains must not overlap - changes made in one domain would affect another domain.

29. April 27, 200529 B.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. Other Things, cont’d

30. April 27, 200530 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