...
Title (Goal) | Controlling access to the repository with relationship driven access control |
---|---|
Primary Actor | System, Administrators, Cataloguers |
Scope | |
Level | |
Story (A paragraph or two describing what happens) | 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:
one that says
and another that says
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:
Both of the above would mean a single policy for each, to support many thousands of individual policy cases. |
...