directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [Triplesec] Permissions, Roles and Groups
Date Thu, 25 Jan 2007 21:11:59 GMT
Ersin pointed me to a very interesting paper 
rbac/rbacSTD-ACM.pdf  that has considerably influenced my ideas on  
where tsec should head, and some of the ideas from that paper are (I  
hope) represented in my comments below.

On Jan 25, 2007, at 11:02 AM, Alex Karasulu wrote:

> Hello,
> I would like to have a discussion on the meaning of these entities  
> in general and with respect to how they are modeled in Triplesec  
> today in the trunk:
>   o Permissions
>   o Roles

I think these are useful abstractions
>   o Groups

I don't think groups are a useful abstraction if you have the right  
kind of roles.

I also don't think it's possible to discuss this subject without also  
including Users and User-Role associations.

> I've been talking to djencks about this stuff for a bit now as we  
> have started working together on various aspects of Triplesec.  I'd  
> like to have a general discussion about these concepts here so we  
> can all be on the same page with what they are.

To me, we get to define our terms, and then they mean what we say the  
mean.  I don't see any of these concepts as having an immutable  
meaning outside what we want the system to do.

Also to set the context here, I think the overall goal is to start  
with something representing the identity of a person using the  
system, possibly some other description of the activities they wish  
to perform, and determine what they are allowed to do in the system.

> Let me kick this off.
> Permissions
> ===========
> To me a permission is a right that is granted to access a resource  
> or perform some kind of protected operation.  To a large degree the  
> semantics of permissions are undefined except within a specific  
> application.  For example the permission to accessPayroll may not  
> have much meaning outside of an application dealing with payroll  
> management.
> In Triplesec (trunk) a permission is just a label without any  
> meaning. The semantics of the permission is left up to the  
> application to define.

I basically agree with this, the label is a meaningless abstract  
identifier.  We do need to make sure we can attach more information  
to the label for specific uses, e.g. attaching sufficient information  
to construct a java permission for use in java apps.  I've done this  
in sandbox/triplesec-jacc2.
> Roles
> =====
> A Role is a collection of permissions associated together to  
> represent the rights need by one to perform the actions or  
> activities of a function.  For our purposes we can just say a role  
> is a collection of permissions.
> As a collection of permissions which are application specific,  
> roles themselves become application specific.
> In Triplesec (trunk) a role is just a collection of granted  
> permissions with a name.  Roles entries in Triplesec have a SINGLE- 
> VALUED 'roleName' and a MULTI-VALUED 'grants' attribute.  You just  
> add the names of permissions to a role entry to add them to the role.

This is really making a big assumption about the meaning of  
permissions, namely that they aren't overlapping in any way, so that  
to deny a permission you just remove it from the set of granted  
permissions.  If permissions overlap, as java permissions can, you  
really need to be able to deny permissions as well.  So you need to  
have roles have a set of granted permissions and a set of denied  

Furthermore, as suggested in the NIST paper, hierarchical roles  
provide great power and convenience for administering roles and  
permissions.  They're fairly trivial to implement in terms of the  
data model, and you don't have to use them if you don't want to.  So  
I'd say a role is <name, grantsSet, denialsSet, rolesSet}

Note that with this role model, you can easily represent any  
combination of existing roles, with individualized tweaks, as another  
role.  Therefore we can represent any set of permissions as a role.   
To avoid duplication of concepts we should represent every  
interesting set of permissions as a role.

Very little I have to say makes sense if you disagree with this....  
the following is predicated entirely on this model of a role.  If you  
don't agree, stop here and lets talk about why.

> Groups
> ======
> Although you can group anything I think we're talking more about  
> groups of users in this context.  Groups are primarily used to make  
> administration tasks easier.  By grouping people and the can be  
> managed as a single group rather than performing the same upkeep  
> operations on all the members of the group.
> In Triplesec a group is a static LDAP group (groupOfUniqueNames) or  
> user DNs right now.  We may expand this to include dynamic groups  
> in the future.

OK, here's where we part company :-)  As the nist paper points out,  
the idea of groups is a precursor to the idea of general RBAC.  We  
definitely need a concept of identity (user), and we definitely need  
a concept of set of permissions (role), and we definitely need a  
concept of associating these two.  Alex is proposing at least two  
mechanisms for associating a user and a set of permissions.  I'm not  
happy with any of the existing associations and think we can do better.

I think these are the requirements:

each user can be associated with several sets of permissions (roles)
each set of permissions (role) can be associated with several users
at any time, at most one role can be active for a user

If we had a relational database this would be pretty easy to model --  
a table with 2 columns, userId, and roleId, both part of the pk, and  
the db would figure out how to navigate for us.  However since we are  
in a navigation-oriented database the best data model depends on the  
expected access pattern.  This unfortunately leads into a discussion  
of typical login capabilities....  Lets start by assuming that we  
start by identifying the user and then try to choose what role to put  
them in, and exactly how we do that is not determined.  Note that  
this is NOT how triplesec is currently organized.

Having decided on an access pattern, our model should look like   
UserRoles { userId, roleSet}.  With this model groups are not needed,  
nor are profiles which Alex didn't mention.

Lets look at how groups and profiles get modeled now.

groups:  The purpose of the administration simplicity alex mentioned  
is to assign a user to a set of permissions.  The set of permissions  
is a role, so you add the role to the users roleset.  This is the  
same action as assigning a user to a group, looked at from the other  
end of the relationship.

profiles: profiles currently have 2 functions, constructing a set of  
permissions out of other roles, and associating that set of  
permissions with a user or group.  The set of permissions is now a  
role, so the remaining function is associating that role with one or  
more users.  This is done by adding the role to the UserRoles for  
each user involved.

Alternate suggestion

As noted profiles currently combine specifying a role (my  
hierarchical definition) with associating a user with the role.  If  
we take out the aspect of subclassing role, we are left with a  
profile containing a unique name, a user id, and a roleId. This is an  
acceptable alternative data model for a n-n user role association,  
although there is no obvious uniqueness constraint on (userId,  
roleId).  Here the user would identify themselves using the  
profileId, the login framework would lookup their userId and  
authenticate them using that, then we would determine the role from  
the roleId.  This is the same access pattern as currently in triplesec.

With this alternate suggestion the admin actions are basically the  
same as with the first suggestion, except you add/remove profiles  
rather than modifying UserRole contents.  In either case groups  
aren't needed.

My basic philosophical objection to including something called a  
group in our model is that it duplicates the ideas we model better in  
roles and user-role association.

Hopefully this is sufficiently coherent that everyone can understand  
what I'm trying to say :-)

david jencks

> Thoughts? Corrections?
> Alex
> <akarasulu.vcf>

View raw message