directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole_er...@yahoo.com>
Subject Re: [Triplesec] Permissions, Roles and Groups
Date Fri, 26 Jan 2007 00:02:17 GMT
OK - So if we have aggregate roles / hierarchical
roles, we can elliminate the concept of groups.

Groovy.



--- David Jencks <david_jencks@yahoo.com> wrote:

> Ersin pointed me to a very interesting paper
> http://csrc.nist.gov/ 
> 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  
> permissions.
> 
> 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 --  
> 
=== message truncated ===



 
____________________________________________________________________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097

Mime
View raw message