Sorry - Group Hiearchy, should actually be "User Hierarchy" below
--- Ole Ersoy <[EMAIL PROTECTED]> wrote: > 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 > === message truncated === ____________________________________________________________________________________ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail
