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
