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
|