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 01:23:33 GMT
Yeah this is really good stuff!

Thanks Guys!


--- Emmanuel Lecharny <elecharny@gmail.com> 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 :)
> 
> Anyway, this is important concepts and this convo is
> really important.
> Thanks Alex, David, Ersin and Ole !
> 
> Emmanuel
> 
> >
> > thanks
> > david jencks
> >
> >
> >>
> >> Emmanuel
> >
> >
> >
> 
> 



 
____________________________________________________________________________________
TV dinner still cooling? 
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/

Mime
View raw message