[Zope3-dev] My take on Zope3 permissions / security.

[Lennart Regebro]

From: "Jim Fulton" <jim@zope.com>
> I like my definition, which can encompass yours, better.
> A role is a responsability. Of course, many organizations
> create positions with responsabilities.

I thought about that, and decided against it, since some roles does not
carry any responsability. If you have a "viewer" role for example, that
carries no responsability.

But of course, in reality the difference is only academic. :-)

> I don't think we should mandate much in the way of meta-data. Perhaps we
> should suggest and strongly encourage meta-data.

True. By defining the set of meta-data for a user in the acl_user folder (or
maybe in the user containers) you still get the possibility of defining a
strict set of meta-data. But there is no reason that some parts of the
meta-data should be there forcefully. Rather full name and e-mail should be
the default properties when you create a new acl_users.

> I don't understand what you want to use the hierarchies for. Are the
> hierarchies only for directory search, or do they imply reuse of
> security information?

Both. It makes it easier when you have many users, it gives you an easy way
of grouping users, and it is also to make it easier to reuse external
directory service information, received via LDAP or so, which is often
hierarchial.

> > The subsystem could be "Zope" for the products that come with Zope core,
and
> > "Formulator", for those permissions, "Easy Publisher" for all the ones
we
> > send with our CM system, and so on. Action would be things like add,
delete,
> > view, send or any verb like that, and object would of course be a
specific
> > type of object, or a group of objects.
>
> Cool, although I don't see a need for "object" categories. I think
subsystems
> cover the same idea.

Yeah, they do..
I saw permission as split in three parts basically, and these were the
parts, but maybe it's just confusing to be able to "filter" on object. The
need isn't that great since there only will be maybe 4 or possibly 5
permission for one object.

> This isn't so different from the current definition of role.

It's very close to yours, yes. I hadn't seen your definition of roles
earlier.

> I think this is a workable policy, but I don't think that it will be
> applicable to everyone's application.

I'm not 100% sure that it will always work, but I still haven't thought of
one case were it will not work.
Maybe one will pop up. :-)

> You should use the verb "organize" and noun "category" rather than
> "group". The term "group" has a specific and pretty standard meaning.

Good idea. That does make it much clearer.

> I think what you want can be achieved with groups.

It is a type of group, that's for sure. What it has that not all groups have
is that you can assign different roles to different pincipals within the
group. Most types of groups doesn't do that, instead the group in itself
designates the permission (hence the common confusion of groups and roles).