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:36:35 GMT
Sorry - Group Hiearchy, should actually be "User
Hierarchy" below


--- Ole Ersoy <ole_ersoy@yahoo.com> wrote:

> 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  
> 
=== message truncated ===



 
____________________________________________________________________________________
No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail 

Mime
View raw message