Page History

Each object is covered by licenses to capture the different permissions for that object. These licenses may be standard ones like Creative Commons or may need to be tailored for specific local requirements.

For example, for read access, we may have a license that says:

• anyone can see the discovery metadata
• only users with a specific role can download the jpeg version of the image

one that says

• library staff can create, update and delete this

and another that says

• administrators can CRUD everything

Licenses exist as objects in the repository, related to objects via a hasLicense relationship.

Access control policies (eg. XACML) are applied to objects indirectly via the license.

So:

object <hasLicense> license(s)

license <hasPolicy> policy(ies)

The relationship to the license is applied at the object creation stage, or through batch updates by administrators through a management interface.

In this way, if we need to change the wording of the license statement, we change only one object, or if we need to revise a policy to cover a different, new, datastream, we change only the policy. This also allows us to manage licenses in the repository rather than separately (and as now, on paper!).

This moves away from hierarchical access control, thereby allowing for flexible collection structures where objects may appear in multiple collections but are secured by their underlying license conditions and not by membership of a collection.

To deliver truly flexible and efficient access control we also have attribute look-up of parameters, for example to support:

• module code (restrict read to members of this moduleenrolled on a specified module of study, as identified by a module code assigned as a role to the logged in user by the authentication process)
• username (restrict update to the creator)

Both of the above would mean a single policy for each, to support many thousands of individual policy cases.