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
