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

[Martijn Faassen]

Garrett Smith wrote:
> Wow, that's helpful analysis! 

Thanks!

> My head's spinning a bit, I confess :-)

I wrote all that to help my head from spinning too much. As Kit (my
business partner at Infrae) tends to say is that Martijn often thinks
by talking about it. :)

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

Right, I think that fits with my analysis.

A principal is simply an agent that has been authenticated by Zope.
It stands in for a real agent, like a user or a program. 

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

I also think that in Zope 3 it should be typical that such grants depend
on context; I think local roles are very important. 

> - A 'group' is a concept that isn't yet supported in Zope 3. In my mind, 
> a group is a list of principals.

Or at least have an interface which you can ask whether the principal belongs
to it. The list doesn't need to be anywhere.

Alternatively it may in fact be enough to be able to ask any principal
in which group it is. In some cases this is more efficient; from 
LDAP servers one can get a list of organizational units a person is
a member of when accessing a user record. This can be translated into a 
list of groups that this user is a member of.

This can be a lot more efficient than querying the LDAP server separately 
whether a principal with id foo is in a particular organizational unit.

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

In a particular location. :)

Yes. And then a workgroup is the following:

A workgroup is a list of users + groups with permission/role grants.
(it looks like there's a concept of 'IRoleGrantable' which is possible
for both users and groups in a location..)

If a workgroup is 'added' to a location, then the user and groups in the
group will gain the specified grants in this location. It's a different
kind of  "macro" than the role or the group again.
 
> 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.

Right, it's an abstraction. Abstractions are more than just conveniences
though; they allow a variety of underlying implementations. No idea
whether that would be useful here, but just wanted to make sure
that 'convenience' isn't taken too lightly.

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

Right, granting the *same* role to all users in the set.

A workgroup is a convenience that saves the headache of granting *different*
users/groups different permissions/roles with the same pattern in multiple
locations.

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

It makes sense to me at least. :)

What worries me somewhat is that Jim for instance was talking about a user
having multiple principals at the same time. This sounds like a
different model than the one I sketched. I think it is possible to 
come up with different models where you tackle group-like behavior
in a different place. I don't know what this model exactly looks like
though (Jim?). What are the drawbacks and advantages of the various
competing models?

Regards,

Martijn