1. Nov. 12, 20011 Database Applications of Role-Based Access Control Sylvia Osborn The University of Western Ontario Nov. 12, 2001

2. 2 Outline of Talk Brief Introduction to Access Control Models Role-Based Access Control (RBAC) Database Applications of RBAC

3. Nov. 12, 20013 Basic Definitions Subject: an entity wishing to access an object Object: the entity on which operations take place or on which the subject acts Access Mode: one of the legal operations that can be performed by a subject on an object

4. Nov. 12, 20014 Discretionary Access Control The owner of an object can give permissions to others at his/her discretion Typical of operating systems and relational databases Basic model here is the access matrix

5. Nov. 12, 20015 Example of Access Matrix

6. Nov. 12, 20016 Storage of Access Control Information The Access Control matrix is typically sparse Stored by rows: called a capability list Stored by columns: called an access control list

7. Nov. 12, 20017 Administration of access control As well as having a right, one can have the right to grant it to others In discretionary models, this is given to owners of the object In some versions of the access matrix model, the grant permission is shown by +

8. Nov. 12, 20018 Example from db2

9. Nov. 12, 20019 Mandatory access control Subjects have labels called their clearance Objects have labels called their classification Labels are arranged in a lattice Access is decided by comparing the two security labels using certain rules (no read up, no write down, etc.)

10. Nov. 12, 200110 RBAC – 3 planes

11. Nov. 12, 200111 Some definitions Role: named collection of privileges Privilege: (object, operand) pair Group: set of users Direct privileges: not available to immediate juniors Effective privileges: direct and all inherited privileges

12. Nov. 12, 200112 Example Role Graph For VP1, Direct privileges are {9,10} Effective are {1,2,3,4,5,7,8,9,10}

13. Nov. 12, 200113 Algorithms Insert a role - 2 algorithms: 1.Insert1(role name, direct privs, juniors, seniors) 2.Insert2(role name, effective privs)

14. Nov. 12, 200114 Example of Insert1 Insert1 Role name: M Direct: {6, 12} Juniors: {L1, L2} Seniors: {VP1}

15. Nov. 12, 200115 Result

16. Nov. 12, 200116 Example of Insert2 Insert2 Role name: President Effective: {9,10,11}

17. Nov. 12, 200117 Result

18. Nov. 12, 200118 Other Algorithms Delete role Add/delete privileges to/from a role Add/delete edges They all restore certain properties: 1.Acyclic (aborts if duplicate roles created) 2.path r i  r k if privs of r i  privs of r k 3.MaxRole and MinRole are always present 4.Display transitive reduction, with MaxRole at top of page, MinRole at bottom, and inheritance of privileges going up the page. All the algorithms are polynomial in the size of the graph and the size of the privilege lists

19. Nov. 12, 200119 Sandhu’s RBAC’96 model

20. Nov. 12, 200120 Relationship of DAC, MAC and RBAC RBAC can simulate MAC and DAC (Osborn, Sandhu and Munawer, ACM TISSEC, May 2000) The DAC simulation uses lots of administrative roles The MAC simulation assumes one administrative role, and is very simple

21. Nov. 12, 200121 Issues for Database Security More granularity types Access to containers implies access to contents Also access to schema information Access to data implies can read schema More operations than simply read/write/execute Some notion of administrative roles whether or not there are roles for users: DBA, sysadmin,etc. Transactions

22. Nov. 12, 200122 How RBAC fits with relational Can look at the permission information and draw the role graph (next example) Role names have to be generated Also did a project which converted from a role graph to DB2 (had to turn off table ownership – control privilege)

23. Nov. 12, 200123 That example from DB2

24. Nov. 12, 200124 Becomes this role graph

25. Nov. 12, 200125 Oracle’s roles A permission can be assigned to a user or to a role Roles can be assigned to roles Thus can get role hierarchies, but - not obliged to have only roles - no role graph or algorithms

26. Nov. 12, 200126 Integrating Two Systems Users - which have names Roles - which have names Privileges - data and operator integrated by database integration techniques

27. Nov. 12, 200127 Basic Algorithm Insert one role graph into the other - possibly with some intervention by Security Administrator Users get mapped to roles they had before - possibly with some intervention by Security Administrator

28. Nov. 12, 200128 Roles and Privileges Disjoint Role Graph 1 Role Graph 2 MaxRole MinRole

29. Nov. 12, 200129 Privilege sets not disjoint, role names are, users may or may not be disjoint If a role from RG1 has equal privilege set to a role in RG2, merge the two roles in the result. Keep track of the mapping of the two roles to the merged role Map users in RG1 to same roles (or what they are mapped to) Do the same for RG2 - may need human intervention

30. Nov. 12, 200130

31. Nov. 12, 200131 Some duplicate role names, no duplicate privileges Needs human intervention Security admin can decide to rename one of them - back to first case Security admin can decide to keep the common role –rename two original roles - keep track of mapping to new role names –Insert new role with common name, and union of the privileges of the two original roles –The new role has no direct privileges

32. Nov. 12, 200132 New Role with common name Role from RG1Role from RG2

33. Nov. 12, 200133 Duplicate role names, duplicate privileges Completely disjoint privileges -- previous case Completely duplicate privileges -- just merge and map one of the names some overlap of privileges -- create a common junior with the intersection of privileges

34. Nov. 12, 200134 New Role with common name Role from RG1 Role from RG2

35. Nov. 12, 200135 MaxRole(DBA1) {rA, iA, uA, rS, uS} Role1(U1) {rA, uA, rS, uS} Clerk(U3, U4) {rA, iA} Admin(U2) {rA, uA, rS} } MinRole System 1, Oracle e.g.

36. Nov. 12, 200136 System 2, automatically generated MaxRole(DBA2) {rA, iA, uA, rS, iS, uS} R2(Dick, Ann) {rA, iA, uA} R1(Tom) {rA, rS, iS, uS} R4(Sue) {rA, uA, rS} R3/MinRole(Harry) {rA}

37. Nov. 12, 200137 Merging Role Graphs MaxRole1(DBA1) {rA, iA, uA, rS, uS} Role1(U1) {rA, uA, rS, uS} Clerk(U3, U4) {rA, iA} Admin(U2) {rA, uA, rS} MinRole1 MaxRole2(DBA2) {rA, iA, uA, rS, iS, uS} R2(Dick, Ann) {rA, iA, uA} R1(Tom) {rA, rS, iS, uS} R4(Sue) {rA, uA, rS} R3/MinRole2(Harry) {rA}

38. Nov. 12, 200138 Merged Graph MaxRole1(DBA1) {rA, iA, uA, rS, uS} Role1(U1) {rA, uA, rS, uS} Clerk(U3, U4) {rA, iA} R4/Admin(U2,Sue) {rA, uA, rS} MinRole1 MaxRole2(DBA2) {rA, iA, uA, rS, iS, uS} R2(Dick, Ann) {rA, iA, uA} R1(Tom) {rA, rS, iS, uS} R3/MinRole2(Harry) {rA}

39. Nov. 12, 200139 Two Mandatory Systems H M1M2 L MaxRole {rA,rB,rC,rD,wA,wB,wC,wD} HR(h) {rA,rB,rC,rD} M1R(m1) {rA,rB} M2R(m2) {rA,rC} LR(l) {rA} LW(l) {wA,wB,wC,wD} M1W(m1) {wB,wD} M2W(m2) {wC,wD} HW(h) {wD} MinRole Liberal *-Property

40. Nov. 12, 200140 H L MinRole MaxRole {rA,rF,wA,wF} HR(h) {rA,rF} HW(h) {wF} LR(l) {rA} LW(l) {wA} Strict *-Property

41. Nov. 12, 200141 MaxRole1 {rA,rB,rC,rD,wA,wB,wC,wD} HR(h) {rA,rB,rC,rD} M1R(m1) {rA,rB} M2R(m2) {rC,rD} LR(l) (merged) {rA} LW(l) {wA,wB,wC,wD} M1W(m1) {wB,wD} M2W(m2) {wC,wD} HW(h) {wD} MinRole (merged) MaxRole2 {rA,rF,wA,wF} HR2(h) {rA,rF} LW2(l) {wA} HW2(h) {wF} Maxrole (generated) {rA,rB,rC,rD,wA,wB,wC,wD,rF,wF}

42. Nov. 12, 200142 Conclusions RBAC is a more natural, flexible way of expressing access control than traditional methods Managing a complex role hierarchy can be efficient Roles are available in relational packages Merging of role graphs can provide a general way to integrate security information

43. Nov. 12, 200143 References Sylvia@csd.uwo.ca NIST: http://csrc.nist.gov/rbac/ Ravi Sandhu’s web page(draft NIST standard is there): http://ite.gmu.edu/list/sandhu/ S. Osborn, R. Sandhu and Q. Munawer. Configuring Role-Based Access Control to Enforce Mandatory and Discretionary Access Control Policies.ACM TISSEC, vol.3, no. 2, (2000) 85-106. M. Nyanchama and S. Osborn,The Role Graph Model and Conflict of Interest, ACM TISSEC, vol.2, no. 1, (1999) 3-33. S. Osborn. Database Security Integration using Role-Based Access Control. in Data and Applications Security Developments and Directions, Thuraisingham, van de Riet, Dittrich and Tari, editors. Kluwer, 2001. 245-257. S. Osborn, L.K. Reid and G.J. Wesson. On the Interaction Between Role- Based Access Control and Relational Databases,Proceeding of the IFIP WG11.3 Tenth Annual Working Conference on Database Security,Chapman \& Hall, Samarati and Sandhu eds., July, 1996, 275--287.