[Zope3-dev] Initial thoughts on the Zope3 security framework

[Guido van Rossum]

> It would be helpful, then, to define the terms.  I can't find a
> definition of "role" in the security proposal.  There are a bunch of
> interfaces and methods that have the word "role" in them, but it's all
> too abstract for me to intuit any specific meaning :-).
> 
> I think the following terms ought to be defined precisely:
> 
>    - principal
>    - role
>    - permission
>    (- group) ?
> 
> An example or two would also help.
> 
> Is a role just a bag that collects permissions?

I'll give it a try...

I think principal and permissions are easy, at least your intuition
shouldn't cause any problems.

- A principal is an entity that can be authenticated.  This is similar
  to a user except that we don't require principals to be humans --
  they could be programs, or servers, or companies, or aliens,
  whatever.  We don't get into the reliability of this authentication
  here (I guess that's a quality of implementation issue. :-)

  Example principals: Jeremy, Guido, the FAQ wizard.

- A permission is a token that is used as a requirement for an
  operation.  There's a mapping from principals to permissions (which
  is expressed using roles; the mapping is also dependent on the
  context, i.e. the object on which the operation is requested and its
  ancestors in the object hierarchy).  A principal is allowed to carry
  out an operation if the required permission is in that principal's
  mapping.

  Example permissions: View ZWiki Page, Create Folder, Delete Image.

Now let me try defining role:

- A role is a set of permissions.  Roles are also dependent on the
  context.  Roles are used as a shorthand for expressing the mapping
  from principals to permissions.  Rather than defining the set of
  permissions assigned to each principals (which would be a lot of
  work since there are hundreds of permissions and there can be many
  thousands of principals), you typically define a small number of
  roles (say a dozen), and then assign each principal a small number
  of roles (often only one or two).

  Example roles: Manager, Editor, Reviewer.

Contrast this with a group: a group is a set of principals.  In the
matrix of principals x permissions, if principals are rows and
permissions are columns, groups are sets of rows and roles are sets of
columns.  Zope2 doesn't have groups, and Zope3 doesn't have them yet
-- but we may add them, because they are useful in some situations.

The similarity between groups and roles comes from the fact that if
you only look at the mapping between principals and permissions that's
they define, each role defines a set of (principal, permission) pairs
that is the intersection of some of rows and some columns -- this is
indistinguishable from the set of (primcipal, permission) pairs
defined by a group.

I think that Jim & Tres claim that groups and roles are different
because the other semantics and connotations are different -- possibly
because groups don't have the context-sensitivity that roles have.
(Of course this is hard to say because we don't have groups yet. :-)

A word on the context-sensitivity.  Any object in the object tree (or
graph) *can* override the mapping between roles and permissions (via
the security tab in the Zope management interface), and/or the mapping
between principals and roles (via the "local roles" link in the
security tab).  Most objects don't change the mappings, however, and
inherit their parent's mappings, and the implementation is optimized
for this case.  It's also possible to define new roles and new
principals at any point in the tree; this is even rarer, except that
it's possible for a single Zope instance to serve multiple domains,
and then it's common that each domain defines its own set of
principals and roles, while there's also a set or principals and roles
in the root of the tree.  More nesting is probably rare.

--Guido van Rossum (home page: http://www.python.org/~guido/)