[Zope3-dev] a note on groups and roles

[Joachim Werner]

> > The other thing is what you call "Place". It's where things just don't
> > work right in Zope 2.
>
> The idea that users are placeful in Zope is pretty crucial.  The example
you
> provide seems like it could be solved with a user folder implementation
that
> filtered its userlist from a central repository based on some attribute
you
> provide.  For instance, an SQL user folder in a place might define the
users
> it knows about with a SELECT * FROM USER WHERE DEPT="Marketing".  Another
> might "show" the results of SELECT * FROM USER WHERE DEPT="Sales", etc.
The
> users would then be defined (dynamically) in this place by virtue of the
> filter.  Then you could put multiple user folders in your site, each with
a
> different filter.  This same concept could be done without SQL or LDAP or
> whatever, of course, by putting some sort of central repository at the
root
> and putting user folders in place that delegate userlistings to it.

Exactly. But the current "default" user folders don't do that. Our Member
User Folder for Kontentor does (with the one exception that the user folder
also acts DIRECTLY as a user folder in the root level).

For larger installations I'd just make LDAP the standard and provide people
with some help (like predefined LDAP Schemas for use with Zope). For smaller
installations we'd need a simple "user storage". I know that be and is been
done with existing means. It's just not in synch with the "official" concept
(if there is any concept in the current implementation ;-))

> > These are proxy user objects that authenticate against a corresponding
> > "real" user in the root folder, but have different sets of roles.
>
> It seems like the thing at your root really doesn't need to be a user
> folder.  It just needs to be a bag of userlike things.  The bag can be
> queried by a real user folder to get a list of users for its place.  The
> real user folder then turns the userlike things it gets from the bag into
> honest-to-god users in that user folder's place.  The fact that the root
> container in your setup is an actual user folder would probably confuse
the
> heck out of me. ;-)  That said, I can see why you might try to do it this
> way.

The problem seems to be that my "bag of userlike things" is what most
non-Zope people would call a userfolder (a folder with user objects in it).
The role mapping that is currently done using user folders could just be a
new tab or a sub-tab in "security" ...

It is also somewhat important to me that User sources should be flexible, so
it might make sense to have other, local user sources that do not use LDAP
or SQL or connect to a different user database or whatever ... - Currently,
user folders mix these things up a bit as they are user sources and
user-role mappers at the same time (while, strangely enough, the mapping to
LOCAL roles is done somewhere else ...)

> > The usual security checks just
> > won't work! Why? I am not totally sure,
>
> I'm so tired that I can't even pretend to think about this particular
> problem right now, but I'm pretty confident of the fact that a user in
Zope
> definitely needs to be placeful.  Zope security just doesn't work without
a
> user having a place, because a) we need to be able to let the user
delegate
> control in his place and b) the security system relies on a user being
> unable to perform actions on objects "below" where his user object is
> defined.

No, the user object can be placeless. Only the permission-to-user mapping
has to be placeful! To stick with your points a) and b):

a) The user can delegate control at places where he is mapped to a set of
"admin"-type permissions (whether those are grouped to a set of permissions
or not)
b) same again. The security system won't let you do things you are not
allowed to do at places where that permission-mapping is neither local nor
acquired (to avoid the "below" thing here) ...

Lennart is perfectly right that "placelessness" can usually be simulated by
"put it into the root folder". Though that is not true as soon as we talk
about more than one Zope instance, but that's a different story ...

> A set of users may be defined centrally, but every user in this set needs
to
> eventually have a place.  This doesn't mean that every user in the set
needs
> to have the *same* place, though.  This is a factoring problem more than
> anything.

See above. I think that only the part of the user folder implementation that
does the mapping has to be placeful. Though there might be an interesting
aspect (that makes things even more complicated ;-): User source objects
have to be placeful in a way: The place of the source object defines who can
administer the user objects ...

> > Did you mix up "below" and "above" here, or do I not understand the
> > concept?
>
> I did mix up "above" and "below" somewhere in my most recent set of mails
> but this wasn't one of those places.  What I meant by "above" here was
> "further from the root".

O.k., I always think the other way round as most "trees" (like the Zope
tree) start at the top and people refer to going to the parent node as
"going one level up" ...

> Actions are always performed against objects.  In most cases, the action
is
> performed in the context of the object.  So if the action is "add a folder
> to the root folder", the context is the root folder.

Yes, but that's exactly the type of tests that don't work properly in Zope
2. They DO work if I directly access a resource via an URL, because then the
AUTHENTICATED_USER is identical with the user that is the nearest
authentication source for the object. But if I test it from somewhere else
as is the case with Kontentor's management interface, this doesn't work
properly. The AUTHENTICATED_USER is the one that is used for authenticating
the first object that is called (e.g. if I have
http://server/folder/index_html, it will give me the user object that is in
folder), but if I display another object on the page that resides in the
parent folder, that one is NOT checked against its own nearest user folder
instead, but against the same user object again. If local roles worked as
advertised, that would be no real problem. But they didn't the last time we
tried ...

To wrap it all up: I think that the concept you describe will do what we
need. But it is essential to make sure that there is a distinction between
user source objects (which one could just call users or principal) and the
places where they are mapped to permissions. The users can be a located at
the root level or be completely placeless, but the mappings have to be bound
to a place.

A last comment about places in general: I is very essential to me that there
is a clearer separation between content hierarchies and the other stuff in
Zope 3. A user folder should not be in the content namespace. It should be
"bound" to a level in the content hierarchy, but not be an actual object
that is displayed via FTP etc.

It seems to be one of the major challenges for ZMI 3 to make the differences
between content objects and other object types clearer ...

Joachim

Joachim