directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [TSec convos]
Date Thu, 01 Nov 2007 06:39:58 GMT
Hi Niclas,

On Oct 31, 2007, at 10:50 PM, Niclas Hedhman wrote:

> On Wednesday 31 October 2007 00:22, Alex Karasulu wrote:
>> Alex:
>>    Summary: Groups are distinct from Roles.  Roles should not  
>> contain Users
>> and are merely a set of permissions or permissions and other roles.
>>
>>     User can be added to groups: Group<Users>.  A user or a  
>> Group<User> can
>> be associated with something called a RoleAssignment which assigns  
>> one or
>> more Role<Permissions> to that user or group.  Roles only contain
>> permissions.  Groups contain users with clear separation.
>
> I have tried to follow this discussion (ain't easy), but let me  
> chip in a
> reflection, that may or may not been covered....
>
> There is difference in "Role" when talking "Roles of User" vs  
> "Permissions of
> Role". Meaning; Any organisation I have been involved with, want to  
> view all
> their users as collections, often called Roles, e.g. "Senior
> Developer", "Network Administrator", "Chief Financial Officer" and  
> so forth.
> Such Role(s) is/are "assigned" to a particular user.
>
> When looking at the applications Permission system, we are also  
> talking Roles,
> as a set of Permissions that Alex is saying above. These roles are  
> often
> defined by the application/resource itself.
>
> At Triplesec level, you want to be able to correlate that CFO (org  
> role)
> implies the role "Finance Package Admin" (app role).
>

I think that Alex and i agree that, if both of these are roles, we  
would  handle this using role inheritance, making the app-specific  
"Finance Package Admin" a sub-role of the enterprise wide "CFO"  
role.  The app developer would associate app-specific permissions to  
the app-level roles, and an operator would assign users to  the  
enterprise role "CFO"  (actually for this role you might need extra  
permissions :-)
I think we also agree on an idea of scopes where the application is  
in a smaller scope than the whole enterprise, and the app-level roles  
are restricted to this smaller scope whereas the enterprise roles are  
attached to larger scopes.

Alex wants the additional ability to call "CFO" a group and say it is  
not a role and can't have any permissions directly assigned to it.   
Along with this new kind of object he wants a new class of  
associations, group-role assigments, and also user-group  
assignments.  This makes the model weaker (groups have fewer  
capabilities than roles) and more complex (there are more kinds of  
things and relationships).  To me it is still an open question which  
model can be integrated more easily with external systems and  
provided with  a UI that administrators  will be happy to use.

thanks
david jencks

>
> Hope you can work out the different perspectives you guys have...
>
> Cheers
> -- 
> Niclas Hedhman, Software Developer
>
> I  live here; http://tinyurl.com/2qq9er
> I  work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug


Mime
View raw message