On Jan 25, 2007, at 4:58 PM, Ole Ersoy wrote:
Hmmm
OK
Suppose we have:
- Role Hierarchies
- User Hierarchies
- URI Hierarchies
For JACC I also need application hierarchies.
The URI hierarchies would be for grouping permission
targets.
A single URI would represent an atomic permission
target. Thus permissions would not overlap with
respect to URI's.
Can you explain the meaning of URI in this context? How does it
relate to a permission?
For instance, most java permissions can be represented as a java
class name, a permission name, and an actions string. For instance:
java class name: javax.security.jacc.WebUserDataPermission
name: /:/admin/*:basic/foo:*.jsp
actions: !GET,POST,FOO:CONFIDENTIAL
I don't think that triplesec should contemplate understanding the
meaning of permissions but instead delegate to an external system,
such as the java permission interface method p1.implies(p2)
Now we are covering everything right?
maybe getting closer :-)
thanks
david jencks
Cheers,
- Ole
--- David Jencks <[EMAIL PROTECTED]> wrote:
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
______________________________________________________________________
______________
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html
