[Zope3-dev] a note on groups and roles

[Chris McDonough]

I'd like to see the security system simplified in Zope 3; it's pretty 
difficult to justifiably document in Zope 2 and it seems to be getting 
more complicated rather than less in Zope 3.  In Zope 3, it seems we've 
got all the old stuff plus some new stuff crammed in.  This is kind of 
disappointing.  I've not had the time to study and comment on what 
exists til now, but it kinda seems like what exists is a mess 
conceptually.  At least (as far as I know) it hasn't really been written 
down in any way that has survived critical review.

The distinction between roles and groups is pretty weird, and I think 
that Jeremy is on to something in suggesting that we consider kicking 
one or the other out of the Z3 security system.  Having these separate 
concepts makes life difficult for documentors and people coming from 
other systems where groups and users are the norm (ala Winnt and UNIX). 
  I dont think Zope is going to truly innovate much in this area (we 
probably lack the time and maybe even the experience) and it would be 
nice to be able to use familiar terminology even if it isn't absolutely 
"correct".

I believe we need to write down some "cornerstone" sorts of definitions 
to let folks review them critically.  Here is my stab at a set of 
cornerstone definitions that I believe should be captured in a new Zope 
3 security implementation; I think they at least partly echo Jeremy's 
proposal:

- Users are entities with credentials, each perhaps corresponding to
   an actual person, but not necessarily.

- Users perform actions.

- Groups are collections of users or groups.

- Places are contexts in which users perform actions.

- Users and groups are always defined within a place.  There needn't
   be any "placeless" users or groups.

- Admins may not define a user or group in a place "above" a place
   that contains a user or group with the same identifier.
   (Preventing the common delegation problem in Zope 2 where
   a less-capable user is capable of "locking out" a more privileged
   user defined at a higher level by creating a user with the same
   identifier but a lighter set of privileges).

- A group can contain users or groups defined "at or below" the place
   in which the group is defined.

- Permissions represent protection of an action or set of actions.

- An action may be associated with only one permission.

- Permissions are defined by developers.

- Users, groups, and places are defined by site administrators.

- Permissions may be granted in a place to users or groups.

- When an action is taken by an identified user, the security machinery:

    - identifies the permission associated with the action.

    - checks the set of permissions granted explicitly to the user

    - if necessary, checks the set of permissions granted to each of
      the groups to which the user belongs.

    - the access check succeeds or fails based on the permission
      for the action existing within the union of the set of permissions
      explicitly granted to the user and the set of permissions
      granted to each of the groups to which the user belongs
      (recursively).

One thing that is different about this set of suggestions than what 
exists in Zope 2 is the implication that principals and groups are 
actually the same kinds of things (perhaps they implement a common 
interface), and that it might be defensible to be able to associate 
permissions with a principal as well as with a group.  This is not the 
case with Zope 2, where you can only associate permissions with roles 
and not with users.  Additionally, this set of ideas obviates the need 
for "local roles" because users and groups are *always* defined in a 
place.  Adding a group and associating permissions with the group to the 
place represented by the root container or to an individual leaf object 
twelve levels deep actually becomes the same operation.

FWIW, relatedly, I don't understand the use of the term "principal" 
instead of "user" for the "entity with credentials" in Zope 3.  I've 
never encountered this term as a reference to a security concept outside 
of Zope 3.  (I may just be sheltered, but I did work as a computer 
security auditor for a couple years, whatever that means ;-) Any 
argument that "principal" is a more correct term than "user" for an 
entity that has credentials seems a little suspect to me.  The 
distinction seems a little impractical and "computersciency".  If the 
goal is to simplify, just call the user a user and be done with it.  If 
people need to stretch their minds a little bit to understand that users 
needn't map 1-to-1 with actual people, so be it, they've been doing it 
for years now with all sorts of other systems.  Foisting the term 
"principal" on them seems kind of gratuituous.

I suspect the main driver for the retention of roles in Zope 3 is the 
desire for some sort of backwards-compatibility.  I'm not sure that this 
should be a goal for the core security system in Zope 3.  Maybe roles 
could be an add-on for Zope 2 backwards compatility?  I dont know if 
this is feasible, but I can imagine plugging in a new security policy 
where roles only become important for backwards-compatibility purposes.

Of course, there are lots of UI issues to overcome with the suggestions 
I propose here.  I'd be interested to hear any suggestions.


Matt Behrens wrote:
> On Fri, Mar 22, 2002 at 06:32:09PM -0500, Jeremy Hylton wrote:
> 
> 
>>The current Zope philosophy advocates a distinction between group and
>>role that is not found in the security literature.  This note argues
>>that Zope's concepts of group and role both correspond to the
>>traditional notion of group, and that roles are a separate and useful
>>concept. 
> 
> 
> The concept of moving groups and roles as we know them now into
> groups' intrigues me, to be sure; it leads me to question why groups
> that are seperate from roles are indeed so badly needed in Z2.  My
> thought is that maybe the real problem today is that Z2's ZMI
> security tab becomes very unmanageable when you start using roles
> to group users, and if we had some kind of better default UI, this
> could work.
> 
> And no, I don't know what that UI would be.
> 
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev


-- 
Chris McDonough                    Zope Corporation
http://www.zope.org             http://www.zope.com
"Killing hundreds of birds with thousands of stones"