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.
thanks
david jencks
Emmanuel
