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.

April 27, 2005 1

The Role Graph Model and Tools for Design of Access Control

Sylvia OsbornDept. of Computer ScienceThe University of Western

Ontario

April 27, 2005 2

Outline of Talk

1. Role Graph Model2. Some Basic Tools3. Information Flow Analysis4. Other things we are working on

April 27, 2005 3

1. The Role Graph Model: Three Planes

(with Matunda Nyanchama)

April 27, 2005 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)

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

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

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

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

April 27, 2005 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

April 27, 2005 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

April 27, 2005 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?

April 27, 2005 12

Prototype Implementation

April 27, 2005 13

Click on a group or user node:

April 27, 2005 14

Click on a role:

April 27, 2005 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

April 27, 2005 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)

April 27, 2005 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.)

April 27, 2005 18

Initial Can-Flow Graph

Example Role Graphwith effective privileges

R3

{(a,r),(b,r),(b,w),(c,r),(c,w)}

R1

{(a,r),(b,w)}

R2

{(a,r),(b,r)}

April 27, 2005 19

After Collapsing Cycles

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

April 27, 2005 21

Algorithmfor each role rk in 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 oif nodes ni, nj contain the same object o

then insert edges ni to nj and nj to ni

for all roles ri, rk permitted in same session by URA or constraintsfor all pairs (ri, o1, r) and (rk, o2, w)

add edge from (ri, o1, r) to (rk, o2, w)collapse cycles

April 27, 2005 22

This example from Sandhu

Gives this flow:

With the constraint that L users are assigned LW and LR, etc.

April 27, 2005 23

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

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

April 27, 2005 25

4. Other thingsA. 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.

April 27, 2005 26

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

April 27, 2005 28

Some properties of Administrative Domains

Administrative Domains must not overlap - changes made in one domain would affect another domain.

April 27, 2005 29

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

April 27, 2005 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