[Zope3-dev] a note on groups and roles

[Joachim Werner]

Hi!

Some comments:

I also think that one of the major problems of the security machinery in
Zope 2 is the current default GUI. The main problem with it seems to be that
every new permission makes the list even longer and less usable. When you
look at an early Zope 2 with just the standard set of Products installed and
an application using a common set of roles like "editor", "reviewer", and
"user", the GUI works perfectly fine. In most cases you don't NEED to
associate users to more than a couple of "common" permissions. It's just all
these "special" permissions like "Add Product X if it is raining and the
temperature is less than y" make the thing complicated.

The other thing is what you call "Place". It's where things just don't work
right in Zope 2. Many Zope developers have experienced the problem: You
often need a central user repository and then define DIFFERENT roles to
people at places (i.e. folderish objects in Zope). Currently there are two
ways of doing that in Zope 2: Putting all users into the root user folder
and granting them local roles (which don't seem to always do what you'd
expect) or adding the users locally and finding some way of synchronizing
the user settings (e.g. via using LDAP or SQL-based user folders instead of
the standard user folders).

The LDAP or SQL thing might work fine, but is too much work to set up if you
just want to use Zope standalone. And it is not really platform-independent.
What we added in our Kontentor project was the concept of "inherited users".
These are proxy user objects that authenticate against a corresponding
"real" user in the root folder, but have different sets of roles.

Now consider the following: We have a dynamic web page generated from
different parts of the website, where people have different roles. The site
is in an "in-place" editing mode and Zope is to evaluate which objects on
the screen should display an "edit button. The usual security checks just
won't work! Why? I am not totally sure, but it seems that in these
circumstances Zope just "sees" one user folder, probably the one the
"AUTHENTICATED_USER" from the REQUEST belongs to. It actually would have to
check each element against the user folder it that is "responsible" for it.
We are doing that on our own now (get the object, get the user folder that
is next in its path and check the user's roles there), but it is really
inefficient.

One last thing: There really exist situations where "anti-roles" or
blacklists of roles a user is NOT granted in a special local part of the
site make sense. Though a working concept of "inherited users" would be able
to do all this, too.

Finally, before reinventing the wheel, looking into existing concepts (LDAP
and ActiveDirectory come to my mind) might make some sense ...

Joachim

Some additional in-line remarks:

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

Yes, there IS a need for "placeless" users: User credentials (address,
password, username) should not have to be managed more than once.
The best way of solving this issue seems to me to actually keep the users
(not their group memberships, just their credentials) outside the folder
hierarchy. The side-effect would be that replacing that "user source" by
another one (LDAP, SQL) would be much more straightforward than now).

> - 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.

Did you mix up "below" and "above" here, or do I not understand the concept?
Wouldn't the admin in ROOT (which is "above"  everything in my
understanding)
have the right to define any user he wants, but the local admins (which
manage objects "below" root) would then not be able to "cripple" that user?

A group can contain users (or groups, which is new to me, as in Zope 2
that's not possible) that are defined at or "above" the place in which it is
defined, yes? Otherwise a root admin could be tricked into granting people
more rights than he wants them to be granted: The root admin grants a
well-known group at a level below root some rights by adding it to a group
at root level. Later the local admin could add anybody he wants to the local
group, and they would be granted rights on the root level, too!

> - 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

Something is missing here: The security machinery has to check the set of
permissions granted to the user in the CONTEXT (or place) of the object the
action is applied on! Let's say Somebody wants to add a folder, he might
have the permission of adding a folder SOMEWHERE else, but not at a given
place ...

>     - 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).