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

[Jim Fulton]

Martijn Faassen wrote:
> Hey,
> 

..

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

Did we say that anywhere?

Only one principal is authenticated for a particular request.



 > Auditing becomes harder, keeping
> track of multiple principals all the time per request is a nightmare,
> etc. Doesn't seem necessary to me.

Principals aren't really for auditing, but about about authorization.
Nevertheless, there is only *one* authenticated principal (unless there
is none) for a request, so auditing shouln't not be a problem.

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

Yes, same for non users.

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

yes

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

In two separate requests.

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

or a user may be weakly authenticated by name, perhaps via a cookie,
and, later, strongly authenticated via some other means.

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

Yup, exactly.

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

You are confusing authentication and authorization.
Principals are primarily objects to attach authorization to.

There is only *one* authenticated principal for a request, This authenticated
principal could be used for auditing.  This principal can be contained in other
principals and, thus acquires their authorizations.


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

I agree with all of that.

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

You don't need to make groups non-principals to do that. You just need
to distinguish the authenticated 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.

Are you suggesting that granting a permission to a group should have the effect
of granting it to the individual principals in the group? If so, I think that
that is a really bad idea. Certainly, when removing someone from a group, I
would expect them to lose any authorizations given to the group members.

 > A role is similarly a non-principal

Right

 > which can
> cause principals to be granted permissions.

Only indirectly.

 > A workgroup is
> yet another such entity. These entities are all ways to grant permissions
> to principals indirectly.

Whew.

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

Good, we don't need another term.

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

Agreed.

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

Yup.

> The document mentions an 'Authenticated' group, which is fine in my
> mind. :)
> 
> All principals are in the 'Authenticated' group except Anonymous.

Right.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org