directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [Triplesec] Permissions, Roles and Groups
Date Sat, 27 Jan 2007 03:54:47 GMT

Lots of good points there, especially with respect to
ticket expiration.

Just one thing though.

Suppose we have an administrator that wants to 
assign joe, harry, and sally the same role.

If we have a hierarchy of users, then joe, harry, and
sally can be grouped at a node above the 
user level, where all the individual user nodes are.

Then the administrator just assigns the the role to
that group.


- Ole

--- Enrique Rodriguez <> wrote:

> I finally got a chance to read the NIST RBAC paper
> and catch up on
> this thread.  In general I like the approach in the
> paper and I really
> like that it gives a spec to base work on.  More
> inline.
> On 1/26/07, David Jencks <>
> wrote:
> ...
> > Another possibility is to have more roles.  So far
> we have been
> > saying roles are associated with the smallest
> application component
> > we are modeling: in the original tsec model that's
> just the
> > application, in the sandbox test data a
> sub-application.  We could
> > have roles at any level of the application
> hierarchy and they could
> > include as sub-roles roles at that level and finer
> levels.  So for
> > the j2ee example, you could have a "top level"
> ADMIN role that
> > included the variously named admin roles from each
> application.  Then
> > you could assign users individually to this top
> level role.
> IMO, matching the paper and what I think is David's
> opinion, we don't
> need to model Groups as anything different from
> Roles.  An application
> might ship with Roles and enterprise admins will
> want to define their
> own Roles.  In both cases they are modeled the same,
> but, to
> Emmanuel's point, we may still call the
> enterprise-defined Role a
> Group in the admin UI to alleviate confusion.
> Incidentally, the OSGi UserAdmin service comes to a
> similar
> conclusion, in that Group inherits from Role.  I'm
> curious if the spec
> authors read up on RBAC.
> > I haven't been able to imagine the user experience
> of administrating
> > either this model or the group model :-)  We might
> need both.
> Again, it seems to me to be a matter more of UI.
> > I'm really glad we're having this discussion on
> the mailing list!
> Yeah, it's great to see "authorization" picking up. 
> I have 2 items of
> "food for thought."
> 1)  The paper states, on p.17:
> "... permissions do not persist beyond the time that
> they are required
> for performance of duty. This aspect of least
> privilege is often
> referred to as timely revocation of trust. Dynamic
> revocation of
> permissions can be a rather complex issue without
> the facilities of
> dynamic separation of duty, and as such it has been
> generally ignored
> in the past for reasons of expediency."
> Eventually we'll come to the issue of how access
> control is
> communicated.  The Guardian approach was LDAP
> queries.  The Kerberos
> model is for Tickets to contain Authorization
> payload, which is what
> Microsoft uses to great success in the enterprise. 
> Authorization
> "dies" when the ticket expires, governed by Kerberos
> Ticket lifetime,
> which is roughly analogous to the NIST-RBAC concept
> of SESSION.  Also,
> Kerberos is naturally "service oriented," in that
> Tickets are given
> out for access to a service, which in the NIST-RBAC
> model is, I think,
> an "OBJS data set" aka application.
> 2)  One of the key capabilities of Greg Wettstein's
> IDFusion is to
> physically separate the authentication store from
> the authorization
> store, limiting the damage caused by a compromise. 
> I realize
> integrating all of this is way down the road, but I
> think this is a
> key point not immediately obvious from his work.
> Enrique

Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.

View raw message