directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From g..@hurderos.org
Subject Re: [Triplesec] Permissions, Roles and Groups
Date Sat, 27 Jan 2007 16:54:05 GMT
On Jan 26,  7:21pm, "Apache Directory Developers List" wrote:
} Subject: Re: [Triplesec] Permissions, Roles and Groups

Good morning, I hope this note finds the weekend going
well for everyone.

> On 1/26/07, David Jencks <david_jencks@yahoo.com> 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.

> 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.

> 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.

> 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.

I've watched the entire Triplesec/RBAC conversation with some
interest.  Just a few observations in the FWIW department.

I've worked on these issues for a long time with field experience in
deployments with tens of thousands of user's.  If I was to provide any
counsel to the group in their efforts I would advocate that this stuff
has to get simpler rather than more complex.

I tend to have deep reservations about RBAC in terms of practical
implementation.  That is neither here nor there.  I appreciate the
desire to have a very flexible, finely grained system for executing
authorization decisions.  This has to be taken in the context of an
industry which is already being paralyzed by staggering levels of
complexity.

If as a community ADS wants to have an impact on IT practice you would
do well to help foster the understanding of a need to separate
'implementation' of authorization from 'execution' of authorization.
The paper which Enrique co-authored with us for the Kerberos
conference in Ann Arbor is on the confluence site and goes into the
details of this issue.

TripleSec/RBAC are about how to execute an authorization decision.  My
advice to the group is to think carefully about how to isolate
execution from implementation.  The struggle in this thread to
conceptualize an authorization model is emblematic of the issues which
drove our work on isolating the two components.

A month or two ago I posted a somewhat lengthy reply to David and
Ersin about these issues.  It may be worthwhile to re-read those notes
and/or read the Ann Arbor paper on the confluence site.

The most fundamental concept which I think IDfusion has gotten right
is the inherent genetic relationship between a service, a user and an
instance of a service.  That relationship provides a natural
heirarchical implementation mechanism for a higher order model based
on TripleSec or any other alternative RBAC based execution model.

Authorization is no different than any other protocol.  The one thing
which has been demonstrated in other venues is the power and utility
of proper layering models.  Until the need for this is understood in
authorization the use of TripleSec, RBAC or any other sophisticated
authorization model will prove intractable in common practice.

> Enrique

Best wishes to everyhone for a pleasant remainder of the weekend.

}-- End of excerpt from "Apache Directory Developers List"

As always,
Greg

------------------------------------------------------------------------------
			 The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org

"Never try to catch two frogs with one hand."
                                -- Chinese proverb

Mime
View raw message