[Zope3-dev] Re: a note on groups and roles

[Martijn Faassen]

Hey,

Whoa, documentation. :)

I'd forgotten about 'no permission mapping' and globally defined 
principals. That's good for performance. Globally defined groups
(which cannot be overridden locally) would also be useful there.

> I haven't read all of the messages in this thread in detail, although
> I've tried to skim most of them.  I think Martijn has a pretty solid
> understanding of the model, or, at least he did at the start.

Yeah, I might have lost it in thinking too much about it. :) I now
think parts of the model as described especially involving 
groups are shaky and should be revised. Most of the model looks sound,
but this area looks like it needs a bit more thinking. I've done it
for you. :)

> I'm open to revisiting the definitions we came up with almost 2 years
> ago.  If we do though, we should use the current definitions as a
> base line.  IOW, any possible debate should start from a study of
> the current documentation.

I'll bring up some specific conclusions from my present thinking that
challenge what's in the wiki. Jim, if you're in a hurry, read 
at least the 'headlines' and the first paragraphs below them.

There can be only one
----------------------

I think saying a user can be multiple principals to Zope at the same
time is opening a can of worms. Auditing becomes harder, keeping
track of multiple principals all the time per request is a nightmare,
etc. Doesn't seem necessary to me.

A user gets identified/authenticated as much as possible (which may lead to
no id at all) and then the user's requests will be associated
with that principal.

Of course there may still be groups of users that share the same
login username/password or certificate or whatnot beyond Zope's 
knowledge or control. But since that's outside knowledge we can't 
deal with it. This is an entirely different concept from real Zope
controlled groups.

It's possible for a user to be two different principals if that
user connects to Zope in a way that Zope interprets as two different
principals. A simple case is a user being Anonymous first, then
logging in. Again this information is outside of Zope and thus
cannot be managed by Zope, as Zope has no idea.

Saying at any time there's just *one* principal doing requests simplifies 
mattersa like traceability -- you can always track whodunnit easily. It has
a range of consequences, though. I think performance will also be
helped.

So:

The principal is the proxy in Zope through which an agent (user or
program) sends requests into the application. Each request only
has a single such proxy associated with it.

Groups are not principals
-------------------------

Since a user can't be represented by multiple principals at the same
time in my view, I have become unconvinced that groups are a kind of
principal. Groups are a grouping of principals. Some minimal
questions that are useful to be able to ask are:

  principal.getGroups()

  principal.isInGroup(group)

  group.isMember(principal)

Some of these can be implemented in terms of others.

group.getPrincipals() 

is *not* a good question to always ask, as groups may be really large
sets or group membership may be determined by other properties of
principals (ip address or user settings or even first letter of the
username :). This question is therefore not always answerable.

Thus, groups may be composed of other groups, etc, whatever you like,
all hidden behind this abstraction. 

Groups not being principals has in my mind an important benefit in
auditing. Instead of only being able to say "someone in group X did the evil
thing"  you'll be able to always trace it back to the actual principal.

This also means that not every entity which can be granted a permission
is a principal. A group is a non-principal which can cause principals
to be granted permissions. A role is similarly a non-principal which can
cause principals to be granted permissions. A workgroup is
yet another such entity. These entities are all ways to grant permissions
to principals indirectly.

groups are not workgroups
-------------------------

I'm not going to talk about workgroups anymore in this mail, except this 
statement that they're really not the same as a group.

Anonymous is a principal
------------------------

There has to be an anonymous principal. This is important for
traceability -- "Who did the evil thing deleting all the objects?"
"Anonymous did it!"

This would indicate that there's a security hole in your application
somewhere.

Anonymous is the best guess we may have as to who is sending
out requests.

There's a group called 'Everybody'
----------------------------------

In Zope 2, everybody can typically do at least what 'Anonymous' can do. 
In Zope 3 since anonymous is a principal this doesn't make sense. In order to
get to the category of everybody, let's just define the group of all
principals.

The document mentions an 'Authenticated' group, which is fine in my
mind. :)

All principals are in the 'Authenticated' group except Anonymous.

Regards,

Martijn