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
