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

[Martijn Faassen]

Jim Fulton wrote:
> Martijn Faassen wrote:
> >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?

I read you to say this for instance here:

> Principals are objects that can be granted access.  When a
> user logs in, they are associated with some number of principals.
> There can be different kinds of principals, like user principals,
> groups, SSL certificates and so on.  The conceptual framework is flexable,
> but implementations may be simpler and less flexable. For example, the
> current Zope 3 implementations don't provide any support for groups
> or certificates.

in http://mail.zope.org/pipermail/zope3-dev/2003-May/006955.html

You also imply this by saying a group is a principal. A user would
have both the user principal as well as the group principal associated,
right?

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

I don't understand how you can say this and say a group is a principal,
then.

Also, I'd think that since principals are the best thing we have to
identify someone, they're also the best thing we have to trace with.

[snip lots of agreeing]
> >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.

Oh? I don't understand where. I believe there is some unclarity 
(possibly just in my mind :) whether a principal is about authentication or 
authorization, though. I have a proxy that issues requests into the
applications, by authenticating (or non-authenticating) myself in some way with
Zope. Then this proxy is authorized through various mechanisms
to have permissions in various locations.

But I can't authenticate myself as a group. So would that mean a
a group isn't such a proxy issuing requests?

> Principals are primarily objects to attach authorization to.

In my mind there's a separation between principals, which have
authorizations directly used by the security machinery, and 
other entities, which cause a principal to gain certain permissions.

Groups have authorizations that are *not* used directly by the security
machinery. Instead, local role assignments to groups cause permissions on 
principals in the group to exist in a particular location.

Local role assignments to principals are similary not 
directly used by the security machinery; instead they cause permissions
to exist on principals in that location.

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

What does 'contained' mean? I hadn't heard about such a concept of
principal containership before.

[snip more agreeing]
> >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.

But what is the use of calling groups principals, then? There are
other entities such as roles, and workgroups, which aren't
principals either. Why make groups be principals? Groups don't issue
requests into the application and they don't proxy.

[unless they are really all principals of a kind, see at the very bottom]

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

No. I've implemented groups functionality for Zope 2, give me some credit. :)

I am suggesting that if there's a local permission assignment to a group,
then any principal in that location will gain that permission in that
location.  Conceptually there's the following algorithm for each
location to determine the list of permissions the principal has there:

  1 add any local permission assignments to this principal at location.
    Recurse by doing the same for parent location.
 
  2 go through any local role assignments to this principal at location. 
    Treat all permissions globally associated for this role as local
    permission assignments, and do what's needed for 1.
    Recurse by doing the same for parent location.

  3 go through any local role assignments to any group this principal may
    be in. Then treat these as local role assignments and do what's needed
    for 2.
    Recurse by doing the same for parent location.

  4 go through any local workgroups assignments that the principal is in.
    Look at the role assignment the principal has for this workgroup, and 
    treat this as a local role assignment. Then do what's needed for 2.

Of course this is not a algorithm that would perform well, just a conceptual 
one.

[lots of snipping where we agree]

Looks like we agree on almost everything, except for the principal
status of groups. Or actually the meaning of the word 'principal'.
That is, the effects described in security are similar, but we may have 
(slightly?) different mental models on how these effects are accomplished.
I hope my conceptual algorithm helps in fleshing out my mental model.
 
If a principal is something you can assign roles/permissions to, then
a group is a principal. But what about roles?

If a principal is a proxy that issues the requests, then I don't see
a group (or a role) as a principal.

You make the separation between the 'authenticated principal' and other
principals, but then these other principals aren't the proxy, right?
Wouldn't it be less confusing to restrict the use of the word
'principal' to proxy? Or are they proxies indirectly? Hmm...

Googling around a lot to see what common usage was of 'principal'
didn't enlighten me a lot (some call groups principals, some don't), until
I ran into a posting by Jeremy Hylton on this very list over a year ago:
(which I recall faintly reading before)

http://mail.zope.org/pipermail/zope3-dev/2002-March/001077.html

The thread also contains interesting followups. 

Jeremy discusses the 'speaks for' relationship which can exist
between principals. He discusses an entity (which he calls group', with the
quote), that can have permissions associated with it, as well as other
such entities speaking for it. I need to think about this model
some more in order to understand it...

Regards,

Martijn