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

[Martijn Faassen]

Garrett Smith wrote:
> Martijn Faassen wrote:
> 
> >I also think that in Zope 3 it should be typical that such grants depend
> >on context; I think local roles are very important. 
> 
> Absolutely -- this is certainly the typical mode for our application.
> 
> >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..)
> 
> It seems we could avoid the new term 'workgroup' if groups could contain 
> other groups.

I don't think so. That's not equivalent to a workgroup. You can grant
roles to a group, but not to a workgroup. "Virtual Groups" composed of
other groups (either intersections or unions) are useful of course, 
but that doesn't look like a workgroup to me either.

A workgroup is a metalevel on top of principal and group. You make your
role assignments in the workgroup itself, and then you can place this
diverse set of assignments everywhere.

That way I can make user foo be a manager and user bar be a author, and
assign this same combo to multiple locations. If user baz appears with
role author too, that's automatically in all those places too, etc.

> >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.
> 
> With respect to *location*, my understanding is that:
> 
>  - Permissions can be associated with roles
>  - Principals can be granted roles
> 
> I'm not aware of any notion of located *principals* -- these are site 
> wide.

In Zope 2 they're local, i.e provided by a acl_users. In Zope 3 I
guess a local principal service?

> While principals can be *defined* in different locations, the 
> principals themselves aren't located. (Maybe I'm confused here.)

Hm.. It would be useful from an optimization/global overview kind of
perspective for all principals to be global, but that means they need
to be uniquely identifiable.

> Similarly, I would expect that groups would also be site wide -- there 
> would no such thing as 'adding' a group to a location. However, I would 
> expect to see a facility that allowed groups to be redefined for a 
> location -- i.e. a group may have a different set of principals for a 
> particular location. This is analogous to 'local role permissions'.

Redefining membership of an existing group would harm possible 
optimizations, though. Managing membership of a group locally is
fine, but having them be known globally would be useful.

Anyway, it's a flexibility/performance tradeoff. Since security checks
tend to happen pretty often I believe performance here weighs in
considerably.

> >A workgroup is a convenience that saves the headache of granting 
> >*different*
> >users/groups different permissions/roles with the same pattern in multiple
> >locations.
> 
> If I am reading this correctly, this functionality can be covered by 
> redefining the principals for a group in a particular location -- called 
> 'local group principals' perhaps?

I don't think so. See description above.

Note that I myself don't really see that many use cases for workgroups,
but I haven't got experience with them and others definitely like them.
Perhaps I'm misinterpreting the concept here though.

Regards,

Martijn