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

[Chris McDonough]

> If you scrap the roles, then it means you either have to assign people to
> groups locally, ie local groups, or you must be able to set the

Yes!  In the current Zope 2 system, some roles are essentially placeless
(ala Anonymous, Manager, Authenticated, Owner... Owner! ;-)) while local
roles and user defined roles are placeful.  I'd like to be able to get rid
of the placeless roles.  There's no need for them that I can figure out if
you've got a root object somewhere hanging around to stick them on, and the
distinction between user defined roles, local roles, and global roles in
Zope 2 is particularly painful to explain without typing "homina homina"
;-).

Note that if you'd rather call what I call groups "roles", it doesn't matter
much to me, there's no distinction between roles and groups to me.  At least
if there is one, it's almost negligible.  Maybe the one difference would be
that I would imagine that a role cannot possess another role, whereas a
group can contain another group.  This is not a limitation I'd like to place
on any new system.

In the model I advocate, all groups would be considered "local".  In the
setup I outlined, you would define a group by visiting a place much like you
do now in the local roles interface of an object in Zope 2.  The act of
defining a group would consist of adding users and other groups to the group
you're defining.

The place could be a containerish item (maybe the root folder) which allowed
its subelements to make use of its group definitions via acquisition or
composition, or it could be a leaf-level item (maybe a page template), where
that particular object is the only object that knows about a group.  To
define a group, you would be presented with a UI that looked essentially
like this (both lists representing multiple select boxes):

User    Group
----    ------
admin   Managers
user    Editors
user2   Reviewers
user3
user4
user5

<<Submit>>

The userlist presented by the interface would be obtained by traversing down
the place hierarchy, asking each user database that is encountered for a
list of users, presenting the aggregate list.

The group list presented by the interface would be obtained by traversing
down the place hierarchy, starting with the object on which you're defining
the group, asking each containing object for its list of groups, presenting
the aggregate list.

You would only be able to perform the user-group mapping if you possessed
the permission "Manage Groups" in the place.  The list of groups would be
filtered by the groups to which you currently belong (so as to not allow you
to grant access via a group that you don't already have).

You would associate users with groups by selecting one or more users and the
groups to which they should belong in this place (and its subplaces), and
clicking a submit button.

You could not associate users with groups while managing the user object,
because it would probably be too expensive to traverse the entire object
hierarchy to gather up all the ad-hoc groups attached to all objects below
where the user is defined unless you kept a registry (which I understand
we're doing in Zope 3 in some way).

An important distinction to what I'm advocating is that two users (or
groups?) may never have the same short identifier (username).  Thus it would
be possible to identify a user or group unambiguously anywhere in the system
by referring to it by name, making it easy to present an unduplicated and
readable list of users and groups without needing to distinguish them
visually by the place in which they're defined.

Maybe it could also be the case that common containers would always allow
the addition of new users to itself (without needing to go through the
special gesture of adding a user folder to the container).

You would also need to associate permissions with a group in a place,
probably somewhere on another form much like the form shown by the Zope 2
"Security" tab.  The Security tab would present an aggregate list of all
users and groups at and below its place and would allow you to associate
each user and group with a set of permissions.

> permissions
> locally, ie local permissions. So your suggestion doesn't obviate the need
> for local roles, it just creates a need for something other that is local,
> since you don't have any roles at all, and therefore obviously can't have
> local roles. :-)

Honestly I don't care whether they're called roles or groups.  But I have a
tough time understand the need for groups/roles that are not placeful and
why we'd want to make that distinction.

> I any case:
> There are a lot of permissions in a Zope system. When adding some more
> products, you get even more permissions. Roles are a grouping of
> permissions, and is neccessary to make the permission system mangeable. If
> you each time you need to locally change the permission settings for a
group
> of a person have to wade through 30-40 permissions and remember exactly
what
> each of them does, you will only end up with giving most people the rights
> to do almost everything.

This is a whole different can of worms, but I would like to see Zope clearly
define a fairly comprehensive "top-level" set of permission objects (e.g.
"Add Content", "Change Content", "Delete Content") that act as
mini-registries and can be "drilled into" for the ability to have
finer-grained control.  When developers register a permission, they would
register it with one of the top-level permission objects.  For example, if
someone wanted to register "Change ZWiki Pages", they would register this
permission with the "Change Content" top-level permission object.

Something like this would allow us to have groups of permissions with a sane
starting point.  It would also facilitate a much cleaner "Security tab" UI.

> The only problem with the Roles system is that people over and over again
> mistake it for usergroups, since they are expecting usergroups. This can
be
> fixed by having some type of usergroups in addition to the roles. Then
> people won't think roles are usergroups, read the documentation and see
the
> light.

Well, you're talking to one of those people, so I'm not entirely
unsympathetic. ;-)

> Also, the Anonymous and Authorized roles should be removed, because these
> are not proper roles, and may add to the confusion of roles and groups.
> Anonymous should be a built-in and non-removable principal. If it helps to
> clear up the roles concept, maybe some other roles like "Author", "Viewer"
> or "Member" should be created by default. But "Authorized" is a state, not
a
> role.

There is no Authorized role currently.. you probably mean the Authenticated
role.  I agree that this is kind of a stretch, but it was necessary for a
couple of our applications (ala CMF) that must present action lists based
solely on roles.  Actually, I think having the global role "Authenticated"
is no worse than having the global role "Owner". ;-)

> > FWIW, relatedly, I don't understand the use of the term "principal"
> > instead of "user" for the "entity with credentials" in Zope 3.
>
> Neither do I. For me "principal" means "headmaster". :-)

After reading the stuff that Jeremy sent over (which does discuss the
concept of a principal), it seems like it may be more common than I though
and I maybe just need to do more reading.  I'm only opposed to it on the
grounds that it's an unfamiliar term to most people, but if it really is
common security jargon, then I don't really have much of a problem with it.