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

[Jim Fulton]

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


OK, then I wasn't being clear.  For each user, there are
potentially several ways they can be authenticated. They are only
authenticated one way per request. That establishes the authenticated
principal.

Principals can imply other pricipals (e.g. groups) for purposes of
authorization.

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

Groups are not authenticated. They include, directly or indirectly,
principals that are authenticated.

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

That's fine, but try to understand that not all principals are used for
identifification. Groups are not used for identification.


> [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,

Read the definition in the glossary. Principals are about authorization.

In *addition*, *some* principals are *also* used for identification.

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

yes

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

Right. You can't authenticate as a group. The principal you do authenticate
as can, directly or indirectly, be a member of a group.


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

Groups are treated no differently than other principals in this regard.


> Local role assignments to principals are similary not 

You meant groups

> directly used by the security machinery; instead they cause permissions
> to exist on principals in that location.

I thnk you are splitting hairs.  I don't see much difference in "durectness",
nor do I consider the distinction important.

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

Groups contain other principals.

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

Look at the definition in the gloassary, which is a *standard*
definition.   A principal is an entity we grand authorization to.
This is certainly something we want to do with groups.

Having said that, by that definition, I suppose that roles become
principals.

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

I have no idea what a workgroup is.

Perhaps roles *should* be viewed as principals, given the definition of
principals.


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

Right

...

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

Right, perhaps roles *should* be considered principals.

I prefer to stick with a standard definition for principal.

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

For some definition of "the proxy", right.

When zope handles a request, a single principal is authenticated for
that request.  That principal, like the request itself, represents the
access to Zope from outside entity (your proxy, I think.)


> Wouldn't it be less confusing to restrict the use of the word
> 'principal' to proxy? Or are they proxies indirectly? Hmm...

No, because the definition of principal we are using is standard.

Perhaps it would help to have a term for the things that are authenticated.
I suggest that these things are a subset of principals, which is why I
have been using "authricated principal".  In a comment on the principal
definition, Zigg suggested "primary principal", which is similar.

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