[Zope3-dev] a note on groups and roles

[Martijn Faassen]

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