directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [Triplesec] Permissions, Roles and Groups
Date Fri, 26 Jan 2007 17:20:07 GMT

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  

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  

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!

david jencks

> Emmanuel
>> thanks
>> david jencks
>>> Emmanuel

View raw message