Here's a set of developer / administrator use cases
that might help:
Challenge
Assigning a role to a single user.
Solution
Combine a role from the permission hiearchy,
with the user (Which is a node at the
lowest level of the user hierarchy)
Challenge
Assigning a permission to a group.
Solution
Combine the permission (Which is a node at
the lowest level of the permission hiearchy)
with the group (Which is a node above the lowest
level in the group hierarchy)
And so on and so forth. I could keep going, but
I'm sure you see the pattern. There is a tree
representing aggregated permissions. A tree
representing aggregated users. And one for aggregated
permission targets or URIs. When 3 nodes from each of
these trees are combined, it forms a complete picture
of what a user is allowed to do.
Cheers,
- Ole
--- David Jencks <[EMAIL PROTECTED]> wrote:
>
> On Jan 25, 2007, at 5:08 PM, Emmanuel Lecharny
> wrote:
>
> > David Jencks a écrit :
> >
> >>
> >> On Jan 25, 2007, at 4:20 PM, Emmanuel Lecharny
> wrote:
> >>
> >>> Ole Ersoy a écrit :
> >>>
> >>>> OK - So if we have aggregate roles /
> hierarchical
> >>>> roles, we can elliminate the concept of groups.
> >>>>
> >>>> Groovy.
> >>>>
> >>>>
> >>> AFAIK, groups are very cool to have if you deal
> with more than
> >>> one application. Roles will be Application
> related, and groups
> >>> will be more Users related.
> >>>
> >>> Those two elements are pretty close, but their
> semantics are
> >>> different, if I understand.
> >>
> >>
> >> OK, so I was hoping to delay getting into this
> additional issue.....
> >>
> >> Would you agree that if there's only one
> "application" then groups
> >> + role <> group assigment is equivalent to the
> direct user<>role
> >> association I was talking about although looked
> at from the
> >> opposite direction?
> >>
> >> For jacc we need some kind of idea of groups of
> applications. I
> >> implemented this by allowing multiple
> appName=foo,appName=bar,....
> >> in dns, in sandbox/triplesec-jacc2. You can
> have any level of
> >> nesting you want, but for jacc you need 2 levels
> (application
> >> and context within the app). I can see having
> groups of
> >> applications you want to administer at once, for
> instance a
> >> portal app together with a bunch of portlet apps
> deployed on the
> >> portal. So I can see a use for 3 levels.
> >>
> >> So what I was actually thinking of is that within
> a group of
> >> applications you'd want all the role names to be
> the same. The
> >> permissions would still be associated with a
> particular "leaf"
> >> application (context for my jacc example) but
> you'd expect to
> >> have the same role names within each
> sub-applications. Then
> >> you'd have the user <> role association at the
> level of the group
> >> of applications that you wanted to deal with
> together.
> >>
> >> There might still be some difference.... I'm not
> sure.
> >
> > Well, I think here we are just playing with
> semantic :)
> >
> > All in all, I really think those things are very
> similar. You can
> > perfectly manage the so called 'groups' within a
> hierarchy of roles.
> >
> > Now, let's talk about real life, I mean, you know,
> those big
> > companies with an IT management which does not
> manage anything but
> > budgets... They just stack applications, and ask
> poor admin to
> > manage roles, permissions, grants and deny, and of
> course all those
> > applications aren't compatible or does not use the
> same semantics.
> >
> > This is a problem. Let say that when using
> 'groups', you allow a
> > sort of flexibility, and you help an administrator
> to create a
> > feeling of comfort (it's easy to create a group
> called 'accountant'
> > including people allowed to access SAP, SAS and
> some kind of web
> > application. The 'roles' will be defined
> application by application. )
> >
> > At this point, real life example could help to
> understand the
> > concept of chaos and babelization we are faced
> with...
> >
> > But, yes, a role hierarchy seems pretty ok if you
> can manage it.
> > And Groups are also another way to do it, with
> different names. IMHO.
> >
> > Ok, I have to further my thinking about all this
> sh*t I just wrote,
> > and maybe tomorow, after a full night, ideas will
> be clearer :)
>
> So I think I am starting to see something about the
> purpose of
> groups.....
>
> suppose you have 10 applications you have to manage
> security to at
> the same time, and they are j2ee apps from different
> vendors, so they
> all come with different built-in role names which
> however mean
> similar things, such as admin, ADM, Administrator,
> etc etc. Now you
> hire a new administrator person and want to give
> them these app-level
> roles all at once.
>
> Groups are one way to solve this, I'm not sure they
> are the best way
> yet.
>
> 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 haven't been able to imagine the user experience
> of administrating
> either this model or the group model :-) We might
> need both.
>
> >
> > Anyway, this is important concepts and this convo
> is really important.
> > Thanks Alex, David, Ersin and Ole !
>
> I'm really glad we're having this discussion on the
> mailing list!
>
> thanks
> david jencks
>
> >
> > Emmanuel
> >
> >>
> >> thanks
> >> david jencks
> >>
> >>
> >>>
> >>> Emmanuel
> >>
> >>
> >>
> >
>
>
____________________________________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
