directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject [Triplesec] [Authz] Alternate Definitions
Date Sat, 27 Oct 2007 21:25:06 GMT
Alex previously proposed some definitions of terms so we can  talk  
about what Triplesec might do and I, thinking they weren't all that  
clear, suggested we use definitions from the NIST paper.  Alex quite  
rightly pointed out that  my proposal has an uncanny similarity to  
suggesting putting vaporware into  production (those weren't his  
words) so I'm going to try to come up with proposed definitions that  
I think are the same as the NIST ones, with a tiny bit of motivating  
discussion.  I'll discuss the problems I see in Alex's definitions in  
a separate note.  I'm also going to leave out discussion of denied  
permissions or roles which although they are pretty useful make  
logical analysis of the meaning of a role a lot more complicated.   
Lets see if we can agree on the positive aspects before we consider  
these negative ones :-)

So, we have actors who want to do stuff to things, and we want to  
decide whether to let them.  The actors are usually people but might  
be services or something else: in any case we'll assume we've figured  
out who they are.

-- Users:  the set of actors who are trying to do stuff.

-- Objects: the set of things the users are trying to do stuff to

-- Operations: the things the users are trying to do to the objects

We start by grouping the things and objects together into  
permissions: a permission is a set of things you can do to a set of  
objects.  More formally

-- Permissions: the set of subsets of the cross product of Objects  
and Operations.  (one permission is a subset of Objects X Operations)

A simple permission might be one operation on one object, such as  
"read this file foo.xml" but more complicated permissions do show up  
such as a javaee web permission "access to urls (in the app) starting  
with /myContext/ except for /myContext/private/ and /myContext/ 

So we could just directly configure a subset of Users X Permissions  
and declare victory, but that is obviously unmanageable.  Instead we  
group stuff together into roles.  On one hand we associate roles and  
permissions, and on the other hand we associate roles and users.

-- Roles: the set of roles.  (so far they are just names)

So, we associate roles and permissions

-- Role-Permissions the permissions assigned to a role, more formally  
a subset of Roles X Permissions

-- Role-Users the users assigned to a role, more formally a subset of  
Roles X Users.

I'm about to make things a little more complicated, but for now lets  
just say a user in a role gets the permissions assigned to that  
role.  So if a user is in a set of roles, they get the union of the  
permissions assigned to those roles.

So this is better than no roles at all, but with a lot of users or a  
lot of permissions, there's still waaaaay too much work to do.  So we  
need hierarchical roles where a role can have children and/or  
parents.  So we figure the roles form a directed acyclic graph which  
defines a partial ordering on the roles.  One very important thing to  
notice here is that it appears to go in opposite directions for  
permissions and users.  If Role1 is senior to Role2 then Role1 has  
all the permissions of Role2 (and presumably more) whereas Role2 has  
all the users of Role1 (and presumably more).  In other words, a  
bigger (in terms of permissions) role has fewer users.

Now for the complicating factor.  Just like your bank safe deposit  
box has 2 keys, one for you and one for the bank,  sometimes people  
want to set up processes where no one person can do it all.   This  
generally seems to be called separation of duty.   There are two ways  
to think about this.  One is that if a user ever has the possibility  
of being in role A (fill out the purchase order) they cannot ever be  
in role B (approve the purchase order).  This is called static  
separation of duty and is a constraint on the Role-Users  
assignments.  Such a constraint is a set of roles and a number n and  
means that no user can have n of the roles in the set.  For instance  
{A, B} and 2 for the purchase order example.

So, maybe this is too restrictive and you just want to make sure that  
the user can't be in the roles at the same time, but if they change  
which roles are active that would be ok.  So we need a concept of a  
user session which is the roles that are active for a particular user  
at a particular time.

-- Sessions:  a session is the set of roles active for a user now.   
So, its a subset of the Roles-User association which is all the roles  
a user could possibly activate.

Now, a dynamic separation of duty constraint is just like the static  
one but it applies to the Sessions rather than the Role-Users  



1. The objects involved in permissions are apt to be really numerous,  
but they typically come in bunches, namely from application modules  
or applications.  Furthermore, you may want to assign application  
specific roles and then aggregate them into larger cross-application  
roles. (for instance this is pretty much necessary for javaee and  
jacc).  So I propose organizing the objects into one or a set of  
trees which we might call scopes, and associating roles with scopes:  
a role could only include permissions using objects in the scope  
(including descendants) and all the junior roles would also be in the  
scope or descendants.

[ I originally called these applications in my triplesec branch, but  
this doesn't seem very  appropriate.  Scope may not be the best  
term.  I don't know how it relates to "scopes" in microsoft AzMan ]

2. Theoretically one should not need denied permissions since you can  
presumably just take the set theoretic difference of the subsets of  
Objects X Actions to get a new permission representing granted -  
denied.  However the representation of permissions may make this  
difficult or impractical so allowing roles to have granted  
permissions, denied permissions, granted roles, and denied roles  
seems to make it easier to fine tune the meaning of a larger role.  I  
haven't investigated the exact meaning of this in terms of the set- 
theoretic model above.  It's pretty easy to implement however.



1. triplesec (trunk) has a Profile feature that Alex has recently  
been telling me he doesn't like any more.  I don't like the  
implementation but I think its for the same purpose as the dynamic  
separation of duty constraints and the session concept.  Basically  
profiles are, to me, statically configured sessions for different  
jobs; enforcement of separation of duty constraints is left up to the  
viligance of the administrator setting up the profiles.

2. These definitions are fairly set-theoretic which may not be to  
everyones taste.  Perhaps due to my previous training as a  
mathematician I find this style a lot clearer than a lot of words.   
In particular I recognize that the extensions are a lot less clear  
than the main stuff.  Maybe we could add more words and keep everyone  
happy :-)

3. With the exception of separation of duty constraints this is all  
implemented in my sandbox triplesec branch.  By no means am I  
suggesting anything particularly good about this, but it is possible  
to implement and if you want to see a possible ldap schema that will  
store this info you can look at it.  Most likely lots of big  
improvements can be made.  This should definitely not be regarded as  
anything other than a proof of concept and it has some major  
practical problems such as not relating to existing external stores  
of user information.

david jencks 

View raw message