[Zope3-dev] Re: a note on groups and roles
Garrett Smith
garrett at mojave-corp.com
Thu Nov 20 11:26:22 EST 2003
Wow, that's helpful analysis! My head's spinning a bit, I confess :-)
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
More information about the Zope3-dev
mailing list