Yeah this is really good stuff! Thanks Guys!
--- Emmanuel Lecharny <[EMAIL PROTECTED]> 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 :) > > Anyway, this is important concepts and this convo is > really important. > Thanks Alex, David, Ersin and Ole ! > > Emmanuel > > > > > thanks > > david jencks > > > > > >> > >> Emmanuel > > > > > > > > ____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/
