SchoolTool Security Policy
==========================

SchoolTool does not use the default Zope 3 security policy, but implements
a custom one.

The most important difference from the default policy is that we do not have
the three-tier group-role-permission model (i.e, a principal can belong to a
group, roles can be assigned to a group or a principal, and permissions can be
assigned to a role).  Instead, we have a two-tier crowd-permission model.

Notably local grants have also been removed, although it is easy to implement
similar functionality using crowds.

Crowds
------

A crowd is somewhat like a group of principals.  While a group is an explicitly
enumerated set of principals (mathematically speaking, g={a,b,c,d}), a crowd is
a set of principals defined by a membership operation (mathematically speaking,
c={x | P(x)}.  The advantage of using crowds is that unlike groups, which are
static, crowds can also react to context objects.  For example, you could have
an 'owner' crowd which only includes the accessing principal if he is looking
at an object that 'belongs' to him.  Therefore, for different context objects
the same crowd could include different principals.


Implementing crowds
-------------------

In Python code, a crowd is an adapter which adapts a context object to
`ICrowd`. The `ICrowd` interface only includes one method:
``contains(principal)``. The context object is the object that we want to
access.  A crowd could look like this:

    >>> from schooltool.securitypolicy.crowds import Crowd
    >>> class OwnerCrowd(Crowd):
    ...     def contains(self, principal):
    ...         owner = self.context.owner
    ...         return owner == principal


Registering crowds
------------------

Crowds are registered in ZCML using the ``<crowd>`` directive, like this::

  <security:crowd
      name="owner"
      factory=".crowds.OwnerCrowd" />

(We are using the namespace http://schooltool.org/securitypolicy for the
security XML prefix.)

As you can see, the crowd is assigned an identifier which can later be used
in security declarations for objects.


Using crowds
------------

Just declaring a crowd is obviously not enough.  You also have to specify
which crowds have what permissions on which objects.  You can do this
in ZCML like this::

  <security:allow
      interface="schooltool.app.interfaces.ISchoolToolApplication"
      crowds="owner managers clerks"
      permission="schooltool.edit" />

The set of objects that should be adaptable by the crowds are specified by
interface.  The ``crowds`` attribute provides a list of crowd ids. If any of the
crowds includes the accessing principal, permission is granted, otherwise it is
denied.

You can have several ``<allow>`` directives for the same interface and
permission. In that case the lists of crowds will be summed.

In some cases it makes sense to provide a permission to a crowd no matter what
the context interface is.  In that case you can just leave the `interface`
attribute out, like this::

  <security:allow
      crowds="owner managers clerks"
      permission="schooltool.edit" />


Inheriting permissions
----------------------

It is sometimes not feasible to specify crowds for each and every object, and
the Zope3-style parent traversal would be handy.  This is particularly useful
for permissions on views, which typically have the context object as their
parent.  A limited form of such traversal has been implemented.

Basically, if no ``<allow>`` declaration (with an explicit interface) is found
for an object, the object's parent is taken (from the attribute `__parent__`).
If the parent does not have a matching ``<allow>`` declaration either, its
parent is taken, etc., until a matching declaration is found.  Note that at this
point the traversal upwards is not continued no matter whether the principal was
in the given crowds or not.

For example, imagine this structure::

  Application -> GroupContainer -> Group -> GroupView

Here, if one ``<allow>`` directive allowed access to the group container, but
another one disallowed access to the group, accessing `GroupView` would fail:

1. `GroupView` would be checked, no matching declarations would be found
2. Its parent `Group` would be checked, a matching declaration would be found.
3. The crowds in the declaration would be checked and access denied
4. There is no step 4.  Note that even though step 3 did not grant access,
   traversal to the parent is not continued.


Permission lookup order
-----------------------

Here is a brief summary of how a permission is checked:

1. All crowds for a permission (specified as ``<allow>`` directives without an
explicit interface) are checked.  If any one contains the principal, permit
access.

2. While an ``<allow>`` directive with an explicit interface is not found for the
context object, take the context's parent.

3. If the principal is in any of the crowds specified in the matching ``<allow>``
directive, permit access.

4. If neither of the previous steps permit access, deny.

(see ``schooltool.securitypolicy.policy.SchoolToolSecurityPolicy`` for the
implementation)
