directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole_er...@yahoo.com>
Subject Re: [Triplesec] Permissions, Roles and Groups
Date Fri, 26 Jan 2007 17:22:05 GMT

--- David Jencks <david_jencks@yahoo.com> wrote:

> 
> 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?


The URI hierarchy is the "Application Hierarchy".

A single application is broken down into a group of
URIs.

So for instance when you press a JSP button, then
browser translates that into a URI.  Parts of the URI
are used to route the request to say Tomcat on some
server in China.  Then tomcat uses the rest to find
the command / action that corresponds to the push of
the button.  But before invoking that it checks with
Triplesec to see whether the Authenticated User has
the permission.

So that's how it would work for "Commands/Actions".

Then for files/resources the URI is just pointing to
some static file on the net, or maybe a dynamic one,
but if it is dynamic we will just lump it in the
"Command/Actions" category.




> 
> 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)


Sure, I'm using URI's just a a unique key that points
to something that a user is requesting permission for.

I think most developers are used to this, so it's
pretty a pretty straightforward concept to explain,
when presenting triplesec developer use cases.

So the URI just represents something that a user is
requesting permission to access.  If permission is
granted, it's up to the application to decide what
that means.

> 
> >
> > Now we are covering everything right?
> 
> maybe getting closer :-)
> 

Yeah - This is hot stuff :-)  Hooah! 

Thanks,
- Ole



> thanks
> david jencks
> 
> >
> > Cheers,
> > - Ole
> >


> >
> >
> >
> > --- David Jencks <david_jencks@yahoo.com> 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
> 
> 



 
____________________________________________________________________________________
Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097

Mime
View raw message