Yeah - The hierarchical role stuff sounds like a must have. +1
--- David Jencks <[EMAIL PROTECTED]> 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 === ____________________________________________________________________________________ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news
