You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2007/11/01 06:50:36 UTC
Re: [TSec convos]
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).
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
RE: [TSec convos]
Posted by Alex Karasulu <ak...@gmail.com>.
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
SNIP ...
> 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.
I agree "assigned" is the verb often used to describe the user-role
association.
> 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.
Right!
> At Triplesec level, you want to be able to correlate that CFO (org
> role)
> implies the role "Finance Package Admin" (app role).
>
>
> Hope you can work out the different perspectives you guys have...
I think we have. Although we don't need groups for RBAC we do need
it for Triplesec since some groups will exist in Triplesec and others
will be phantom objects whose members are defined outside of
Triplesec like in Active Directory. I'm looking into these details.
Alex
Re: [TSec convos]
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 01 November 2007 14:39, David Jencks wrote:
> 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
Inheritance sounds to be the wrong term for an "Implies" stereotype.
The "Finance Package Admin" is potentially "sub-role" of many org roles, and
IMHO has no "family relationship" between the two. And if you try to put that
into documentation (which indeed could express it differently), my guess is
that many people will be confused.
Now, to the Group; I agree with Alex that "Group" is a very well understood
concepts, and seldom overloaded.
Warning; Funky syntax;
public interface Group<T> extends T
{
void add"T"( T member );
void remove"T"( T member );
Iterable<T> get"T"s();
}
and for any permissions implied by T is granted to all members of the group.
Barely complex, and has its own purpose outside the Role scope.
Cheers
Niclas
Re: [TSec convos]
Posted by Alex Karasulu <ak...@apache.org>.
On 11/1/07, David Jencks <da...@yahoo.com> wrote:
>
> 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.
No this is not a correct representation.
BAD EXAMPLE WITH CFO: CFO is a bad choice since it's the Chief (single)
financial
officer which can only be assigned to one user.
BETTER EXAMPLE WITH SalesRepresentative:
Let's say we have a SalesRepresentative role. Then I may create a group
completely separate from that role called a SalesRepresentativeS: note
capitalized last S to stress the presence of an extra S.
Then I would create a role_assignment with a reference to the
SalesRepresentative role, and a reference to the SalesRepresentativeS group.
This association now makes it so anyone added to the SalesRepresentativeS
group
automatically gets assigned to the SalesRepresentative role. They now have
all the permissions in this role.
BACK TO CFO:
For the CFO I would simply not create a group at all. Instead I would just
make a role_assignment with a reference to some user and a reference to the
CFO role.
This allows me to easily conduct searches for assignments based on the
role_assignment
objectClass to see immediately who is in the CFO role.
This makes the model weaker (groups have fewer
> capabilities than roles) and more complex (there are more kinds of
> things and relationships).
Dude roles and groups are not one and the same even if they can be modeled
that way.
Alex
Re: [TSec convos]
Posted by David Jencks <da...@yahoo.com>.
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