[Zope3-dev] a note on groups and roles

[Lennart Regebro]

From: "Jeremy Hylton" <jeremy@zope.com>
> I believe the current Zope philosophy is this:
>
>     A principal corresponds to a user, e.g. Jeremy.
>
>     A group is a set of principals, e.g. Jeremy is in group PythonLabs.

Well, currently Zope doesn't have any groups at all, so what the Zope
philosophy in that case is a bit fuzzy. :-) But yes, a group would be a set
ofprincipals.

> Groups and roles serve the same purpose.

Well, not really. But if groups do nothing more than group principals, then
groups are only a way to make assignments of one principal to several roles
quicker.

Your group' scheme may simplify the implementation of groups and roles, but
infortunately it doesn't make the security any easier to explain to
outsiders, because you then end up with two different types of groups' that
act slightly different, or you'd end up with a concept of group' that is
highly abstract.
I don't think people will generally understand when you say that "a group'
speaks for principals". I myself had to think about it. Abstraction can be a
good thing, especially if it leads to higher functionality or flexibility
but it doesn't in this case, it's just a nother way of looking or
implementing grous and roles.

Workgroups
==========
So, to the Torped take on the whole thing. I'm calling this workgroups to
distinguish it from groups and groups'. :-)

A workgroup is a set of principals. But you set up a workgroup just like you
would set up the local roles for a folder, ie, you do not only assign users
to the workgroup, *you also assign roles to them within this workgroup*.

When setting up a workgroup the members of it don't get access to anything
but the workgroup itself. But, you can then add any number of workgroups to
a Zope folder, and the users in that workgroup would get the roles they were
assigned in the workgroup to that folder.

That way you still get the grouping and indirection that you get from other
groups, but you also get a greater automatic granularity in that grouping.


In technical terms
==================
So, in technical terms a workgroup is macro of role definitions. When you
add a user to the workgroup and give him a Reviewer role, he will get the
Reviewer role at all the folders where the workgroup is added to the
workgroup list. The workgroup "Boss" will get the "Boss" role in all the
places where this workgroup is added.

With normal grouping, you typically have one group per department, and give
that department access to a couple of parts of the database. Then you have a
group of the Bosses that have more access. But usually this means that all
the Bosses have Boss access everywhere where bosses have access, which is
not necessarily what you want.
To get around that, you would have to split the departments into loads of
groups, one group for each role in each department. Workgroups solve that.

As related to real life
=======================
The nice thing with roles is that it maps very nicely into real life. In an
organisation a person have one or several roles in each area, and in these
roles he/she needs to do certain things. This maps perfectly to have
principal having one or several roles which gives the principal a set of
permissions.

When this needs to be extended with some kind of "grouping" of principals,
it's easy to get stuck "how did they do that in <insert favourite security
system here>". And since most people here have used unix or NT, you start
thinking of making groups of principals, because thats how everybody else is
doing it. *But*, that doesn't fit well with the innovative roles concept.

In any big organisation there are different types of groups, like
departments, teams, taskforces. But very seldom does everybody in that group
have the same role. In each department there are a department boss. The
teams have team leaders, and so on. The workgroups concept is therefore a
much better match for how organisation is done in reality. You have some
sort of group, where different people have different roles within that
group.

This workgroups concept take the grouping of principals one step further,
and extends on the Zopes brilliant roles system, rather than patch over it.
It is not just one level of indirection, but an extention of Zopes security
system to match larger organisational structures.


Best Regards

Lennart Regebro
Torped Strategi och Kommunikation AB