[Zope3-dev] a note on groups and roles

[Martijn Faassen]

Lennart Regebro wrote:
> Martijn Faassen wrote:
> >I'm not sure what you mean here. Roles should be assigned to groups just 
> >like
> >to any other principal like a user, so why is a separate service needed?
> 
> No, because that may not be the case at all. For example, the groups may 
> contain role assignments in themselves.

Okay, you're talking about an altogether different kind of group then.
Shouldn't be carefully distinguish this concept and call it 
'workgroup', as in the proposal referenced?

The concept of a group meaning that everybody in that group has the
*same* role assigned to them is extremely useful all by itself. You can
assign a class of users a role (like 'allowed to access this part of the site').

This concept of group is *not* the same as the concept of role, either.

[snip]
> Roles and and simple groups are both sets of groupings, to allow you do 
> assign a fixed set of permissions to users. They therefore overlap in a 
> way that doesn't extend the flexibility much.

I disagree. I find what you call 'simple groups' extremely useful already.
It allows you to update group membership separately from local role
assignment. This way if the organization changes you only update the groups,
not the local role assignment. Frequently large organizations already
have this kind of grouping service already available in LDAP servers.

A workgroup as defined seems to allow you to map different roles to different
members. Workgroups themselves cannot have roles assigned to them. A
workgroup is just 'added' locally somewhere and then in effect all the
principal->role mappings inside will be added to this place.

I am not sure if groups are a kind of simple case of a workgroup. I don't
think so, as with a group you in effect assign role A to all its members 
in location 1, and role B to all its members in location 2.

With workgroups, you can assign the same set of roles to a particular
member in *all* locations the workgroup is in use.

> By letting groups contain 
> role mappings you add another dimentionality on the access control. Much 
> neater.
> 
> If we DON'T implement flexibility in this, and have just a fixed built 
> in non-replacable and non-exendable type of groups, I think at least 
> this should be implemented, so we have groups that are really useful.
> 
> Of course, nothing prevents you from assigning roles to these groups 
> too, and hence you can get bort worlds. :)

I don't think conflating the workgroup concept with the group concept
this way is very useful if what I say above about workgroups and groups
offering different functionalities is true.

With groups, you look up the effective roles of the request
for a particular location by checking the user->role mapping and then for 
any group that the user is in the group->role mapping.

With workgroups, you look up the effective roles of the request by 
looking at any user->role mapping and then for any workgroup added in
the location any other user->role mappings.

I guess if you added a generic hook in the right place you could 
possibly account for both cases, but I am not sure whether that is
useful in the light of the following:

There are use cases where it is really useful to be able to
have 'global' knowledge about security information, for instance when
you want to efficiently filter catalog resultsets based on the user's 
permissions. Last year Steve and I and Jim had some discussions about this 
kind of thing here at the Rotterdam sprintathon. If you want to
have somekind of global reasoning model for security that could mean
you have to put some put some constraints on the
security hooks in the name of efficiency. For instance, if group membership
is defined globally, you only need to calculcate what group a user is in
once per request, not once per object (which you'd need to do if there
were hooks or locally defined groups). In addition
you couldn't write code that reason about such a flexible situation very
easily either.

Note that defining something globally doesn't mean the information has
to be *managed* globally. In Silva, groups are global (to the silva instance)
but their membership is managed locally by users who have the appropriate
rights there.

Regards,

Martijn