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:34:15 GMT
Here's a set of developer / administrator use cases
that might help:



Challenge

     Assigning a role to a single user.

Solution

     Combine a role from the permission hiearchy,
     with the user (Which is a node at the 
     lowest level of the user hierarchy)


Challenge

     Assigning a permission to a group.

Solution

     Combine the permission (Which is a node at 
     the lowest level of the permission hiearchy)
     with the group (Which is a node above the lowest
     level in the group hierarchy)

And so on and so forth.  I could keep going, but
I'm sure you see the pattern.  There is a tree 
representing aggregated permissions.  A tree
representing aggregated users.  And one for aggregated
permission targets or URIs.  When 3 nodes from each of
these trees are combined, it forms a complete picture
of what a user is allowed to do.

Cheers,
- Ole





     
     


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

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



 
____________________________________________________________________________________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

Mime
View raw message