Again I am condensing out the agreed to points ...
I figure that if we decide that groups as distinct from roles are not conceptually necessary, even though they are in most existing systems, we can then think about whether it's practical to write code that only uses roles, not groups.
I don't know if this is practical,
but I think it's worth thinking about without throwing up our hands and saying its too hard.
For instance, it might be possible for our role objects to be backed by either tsec roles (in the part of ldap we control) or AD groups. Obviously the role objects backed by AD groups are likely to be read-only from tsec.
Plus it's just not natural. Groups exist. Roles exist. They are not the same to the majority
of administrators out there. So why push it if it's going to alienate people and create more
problems and work for us.Isn't this a UI question?
Administrators are not likely to be poking around in our code to see what we named our objects.
What if whenever you get to group users together or construct a "group hierarchy" we call the unnameable object a group and whenever you get to associate permissions to it or construct a "permission hierarchy" we call it a role?
My approach now after analyzing existing products is to use a role-assignment
not only to users but to groups. Hence a role-assignment associates either a user
or a group with a set of roles.If we have groups, we obviously need to associate groups with roles. If we agree to call the "groups" roles, the group-role association becomes part of the role hierarchy.
Now if I
understand what you are proposing it is to have a "group" which has a
set of users associated with it (like a role) and has roles
associated with it.
No the group is just a group. It sits out there. The role-assignment is what is our
join table used to associate the group with the roles.I'm not claiming that the association is stored in any particular place. If you want to claim that the role-assignment is an object then we will have to make all the associations objects so we don't bias the discussion by implementation details about which end of an n-n relationship we store the pointers.
It's not just some ONE else. It's the majority of systems out there. I'm telling
you that by pissing straight against the wind on this one your going to have us wet
and dirty :).
Let's look again at the division of labor:
- creates, deletes, modifies users
- creates, and deletes groups
- adds and removes users from groupsso AFAICT the model I'm talking about supports this just fine, provided the UI these people use labels the roles "groups".
When you hire joe, you have to group him with the other people who do the same kind of work. Whether we call the object a role or a group, its the same amount of work.
(2) policy maker (technical security officers)
- create, delete, role assignmentsI think these are the group-role associations? To me these are some of the role-role hierarchy relationships.
- create, delete role exclusions (for static separation of duty)
(3) application architects (engineers & developers)
- create, delete, modify permissions
- create, delete, modify role names
- add, remove permissions from roles
With role hierarchies:
- add, remove roles from rolesI agree with all these tasks. I don't agree that they favor or disfavor having groups in the model.
Maybe. If these are group-role assignments I think this is a much more complicated harder to understand way of implementing separation of duty constraints.Having multiple named role-assignments accomplishes this same goal.
If we have groups I think having a session that contains the currently active groups and (directly assigned roles) will be much easier to implement and understand than trying to do SOD at the group-role assignment level. I could be wrong but I think this might well outweigh the difficulties in writing java-ldap mapping code from a role object to both ldap roles and groups.Anyway I'm not sure we need to implement all of SOD right away.
Well I'm sure you completely agree with my arguments by now :-)
but in case you don't :-D I wonder if we can move forward anyway?