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

[Garrett Smith]

Wow, that's solid analysis -- it will be great to nail these concepts 
down :-)

As a layperson, my understanding of Zope 3's security model is this:

- When I see the term 'principal' I translate it in my mind to 'user'. 
Anything more abstract than 'user' is esoteric to me at this point.

I understand that the generalized 'principal' is to cover cases where 
the 'user' is not human or 'user' is a human + something else (e.g. a 
human authenticating with a particular certificate, from a particular IP 
address, etc.) I try not to read too much into this naming convention -- 
it's just a broadening of the traditional 'human user' concept.

- A 'permission' is a token that lets a principal do something. Without 
the requisite token, a principal is forbidden from performing an action 
(e.g. read, write, delete, etc.)

- A 'role' is a list of permissions.

- A principal can be 'granted' permissions and roles. This is really 
just saying that a principal is granted *permissions*, since roles are 
just groups of permissions. Grants can depend on things like context 
location -- e.g. a principal may be allowed to edit in one part of a 
site but only view in another. Grants can be explicitly denied.

- A 'group' is a concept that isn't yet supported in Zope 3. In my mind, 
a group is a list of principals. A group is not a principal but it can 
be granted permissions/roles just like a principal. Granting a 
permission/role to a group is merely the expression 'grant this 
permission/role to every principal in the group'.

I see groups as being to principals what roles are to permissions. A 
role is nothing more than a convenience -- it saves the headache of 
assigning the same set of permissions over and over. Similarly, a group 
is nothing more than a convenience that saves the headache of granting 
permissions/roles to the same set users over and over.

That said, I now brace myself for the possibility that my comfortable 
'Zope 3 security model' world view is totally off base ;-)

  -- Garrett


Martijn Faassen wrote:

> Steve Alexander wrote:
> 
>>>To me a principal is anything which can get a role assigned to them. :)
>>
>>Let's say I choose to make roles able to imply other roles. That doesn't 
>>make a 'role' a principal, does it?
> 
> 
> Is this a serious question? This was not intended to be a bullet-proof
> statement closed for misinterpretation. :)
> 
> But you're right in that this semantic discussion seems important. So
> I'll drop in another statement:
> 
> Making a role imply another role doesn't sound like 'assigning a role
> to a role'. The role doesn't *have* that role.
> 
> (more semantic discussion below)
> 
> 
>>I thought the whole point of calling them 'principals' instead of 
>>'users' was to support concepts such as several users being jointly 
>>responsible for some action or request, and to represent agents that are 
>>responsible for actions that are not actually 'users', such as certificates.
> 
> 
> I'll first explain why I have the impression groups are a kind of
> principal; I heard people refer to groups this way several times
> before. Jim, for instance:
> 
> http://mail.zope.org/pipermail/zope3-dev/2003-May/006955.html
> 
> 
>>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.
> 
> 
> Later on it mentions you: :)
> 
> 
>>On IRC, Steve suggested that principals and "users" ("members") might be
>>different objects and that principals are adapted to users, where principals
>>are meta-content and users are content. Another way to look at this is
>>that, perhaps, users/members are content and principals are associated with
>>users. Users are content and (for some principals) you can get a user from a
>>principal.
> 
> 
> [ignoring the content/meta-content discussion that was the topic of
> Jim's post]
> 
> Anyway, from this thread and some re-readings of things said earlier,
> it seems that the word 'principal' is far less clearly understood 
> by the Zope 3 community than previously suspected. It's good that we
> found this out. I think I now understand better where Steve and
> Lennart are coming from.
> 
> Anyway, first some statements to help thinking along:
> 
>   * a principal has a unique identity in the security context. A principal
>     can be traced -- it is known which principal is taking this action. 
>  
>   * a principal does not have to be a user; a principal can be a program
>     connecting to Zope for maintenance duty, for instance.
> 
>   * Can certificates be principals? Above you state they can be agents,
>     but I don't really see this. An agent can *have* a certificant however
>     to enable Zope to uniquely identify the right principal.
> 
>   * Is a principal an agent?
> 
>   * Does it really make sense to have a user be represented as multiple
>     principals? Does this make these principals jointly responsible for
>     actions? If not, how to pick the right one? Is this traceable?
>     Doesn't the concept of 'role' capture part of this semantics instead?
>     Roles aren't traceable and aren't agents, but they're assigned to
>     traceable agents.
> 
>   * Can a principal then be a group? Or is a group something that influences
>     the roles of a user in a particular location, instead? A workgroup
>     is a different kind of entity that could be seen as influencing the
>     roles of a user in a location. A group is assigned roles in a location,
>     while a workgroup is just declared to be present in a location.
> 
>   * There need to be ways to identify which traceable agent generated
>     a request. You can do this on username/password basis, certificate,
>     even ip address.
> 
>   * Some confusion comes in here with the group concept.
>     If a certificate or ip address is the cause of identification, it may
>     in fact be a group of users (or programs) using the same certificate/ip
>     address (or even username/password :). This is grouping functionality
>     but there is a difference here that such group membership cannot be known
>     by the system.
> 
> Now to try to come up with a more consistent story answering some of these
> questions:
> 
>   * principals are traceable agents that have roles. These roles can
>     come from a number of sources.
> 
>   * strategies exist to identify (authenticate) a request as coming from a
>     particular principal based on password information, certificate, 
>     even ip address.
>   
>   * Anonymous is a principal because this is in that case the best
>     identification we can make based on the information.
> 
>   * Authenticated is *not* a principal because when authentication
>     happens we always have a better identification of the agent.
>     A principal can *be* authenticated or not (in which case it is 
>     anonymous). There are other states based on the identification a 
>     principal could have (certified, for instance). I think such states
>     could be codified in Zope 3 using interfaces.
> 
>   * The roles of the principals in a particular location are somehow
>     discovered/calculated/looked up. 'Role munging'. This is the process of
>     authorization (or applying authorization information).
> 
>   * A simple way of making a principal have a role somewhere is to assign a 
>     local role to that principal in a location.
> 
>   * More complicated roles exist as well. Various kind of role lookup
>     strategies can be used to create concepts like groups, workgroups.
>     (Lennard)
>   
>   * Role munging strategies can of course also take authenticated status
>     and other information on the principal into account in order to assign
>     roles. It could also take ip address into account. In this case ip address
>     is not used for authentication but for authorizing. 
> 
>   * Roles assigned to an agent due to the above strategy is a separate concept
>     from roles assigned to a conceptual user and/or program due to the above
>     agent authentication process. It is impossible for Zope to know anything
>     about this.
> 
>   * It is useful to implement a group system (where a group can
>     be assigned roles in locations) as a higher level abstraction than pure
>     generic role munging. Pure role munging can still be used to implement
>     special things like workgroups, but things like assigning roles based
>     on properties of the principal (ip address information, information
>     coming from LDAP, etc) can be implemented on top of the group abstraction.
> 
> What do people think? Perhaps this was already obvious to some, but I think
> I've introduced some clarity for myself here. :)
> 
> Regards,
> 
> Martijn