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