directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject Re: [Triplesec] Permissions, Roles and Groups
Date Sat, 27 Jan 2007 03:21:03 GMT
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.


View raw message