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 <[EMAIL PROTECTED]> 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
