[Zope3-dev] Security Model

[Shane Hathaway]

I did not realize until today how similar Zope's security
infrastructure is to that of Oracle.  I find that encouraging, since
Oracle has fulfilled the needs of a diverse audience for a long time.
Zope's permissions are like Oracle's privileges and Zope's roles are
like Oracle's roles.

Zope lacks a very neat feature, though: in Oracle, you can grant a
role to other roles.  I don't think this capability is yet planned for
Zope 3.  Roles that support inheritance could be an excellent way to
simplify security.  We would get to use the same machinery for roles,
groups, and workgroups.  I'll explain how.  If you're in a hurry, skip
to the last paragraph.

Many of Zope 2's security abstractions are fundamentally the same kind
of abstraction.  Users map to roles, roles map to permissions, and
permissions map to methods.  Every Zope object has the opportunity to
influence these mappings.  To check access to some method, the
security policy follows the security mappings as they appear in the
context of the thing being accessed.  If there is any contiguous chain
in the links from the user to the method, access is granted.

So Zope 2 has three security mappings, which is good for a lot of
people, but three is a fishy number.  Some people might need more
abstractions, and some less.  Hence Zope 3 introduces new mappings to
solve that problem: you can assign to users to groups, and groups to
roles, yielding 4 mappings.  Or you can map users (or groups) directly
to permissions, yielding 2 mappings.  For kicks, you can map users to
groups to permissions, yielding 3 mappings in a different layout.  And
to make things really interesting, there are also permission
categories (or whatever they are called), letting you stretch out to 5
mappings.  The concept of workgroups, as I understand it, would add
yet another mapping.

All of these mappings seem to do the same thing--they form links in
the chain from user to method.  The only differences I can identify
from an implementation perspective are that some are global rather
than context-dependent, and that they are managed by different people.
The mapping from permission to method is managed by software
developers rather than site managers, for instance.

If you add inheritance to any one of those mappings, that mapping can
fulfill the purpose of other mappings.  For example, if the user 'Joe'
maps to the group 'Managers', and the group 'Managers' maps to the
role 'Editor', you could equally model that by replacing groups with
roles and mapping 'Joe' to the role 'Managers' and the role 'Managers'
to 'Editor'.  Note that a lot of people tried to use roles as groups
in Zope 2, but this generally failed because roles could not inherit
from other roles.  The chain still only had three mappings.

Introducing inheritance lets you make the chain as long as you want.
It would allow great flexibility while reducing the number of concepts
we have to keep track of.  Site managers would be able to make their 
security mapping chain as long as they want, while Zope 3's code would 
only need to be concerned with the abstract concept of mapping one 
security moniker to another security moniker.

I see two strategies for inventing a user interface based on these
concepts.  We could call everything managed by site managers "roles".
I presume this is basically the route Oracle takes.  What would be
much cooler would be to let site managers define their own security
nomenclature.  When you add a security moniker like 'Editor', you
would also select what kind of moniker it is: a role, a group, a
workgroup, a privilege, or whatever moniker types you've set up
beforehand.  On a different form, you could map that moniker to users,
permissions, or other monikers.

In conclusion, I think we can unify a lot of Zope's security concepts
and push the differences between roles, groups, and workgroups into
the user interface.  I suspect that supporting this model would go
beyond simply replacing the security policy.  On the other hand, the
new flexibility would reduce the need to ever replace the security
policy.  I also think it would reduce the complexity of Zope 3.

Shane