[Zope3-dev] a note on groups and roles

[Chris McDonough]

> I also think that one of the major problems of the security machinery in
> Zope 2 is the current default GUI.

I agree.  It would be nice to fix this with "permission groupings" ala my
last mail.

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

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

I'm not sure what you mean by "the usual security checks", but I can easily
imagine Zope bugs that might cause the problems you describe.  The fact that
there are these kinds of bugs (we've seen lots of them ;-) might be
attributable to an overly complex implementation and/or design.  There
weren't even a set of unit tests for the security system in Zope 2 until
about six months ago.  This was partly because people didn't really
understand what it was *supposed* to be doing. ;-)

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

I agree... I dont know enough about common security patterns to reinvent any
wheels. ;-)

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

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.

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

> Wouldn't the admin in ROOT (which is "above"  everything in my
> understanding)

In my description, the root is "below"... like a tree stands upright with
its leaves "above" its "roots".  I often think about the root being "above"
the leaves too, but it's not the way most people think of it.

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

That's the intent.  They wouldn't be able to define a new user with the
same name but different roles, thereby crippling access to that part of the
site.

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

A user's scope of control should exist only at and "above" the place at
which he was defined,  just like the current Zope 2 implementation.  If he
were the member of a group defined at a lower place, that group membership
would only be meaningful in the context of objects at or above his place.

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

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.