...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Hydra permissions, which are essentially read/write, seem to follow a file-system paradigm. Digital objects, however, are not monads like files, but are fundamentally composite assets. Also, file system permissions are easy and efficient to change at scale; digital repository objects (at least as we know them in Fedora/Hydra) are not.
However, even if efficiency were not an issue, "permissions" do not really reflect how a repository user interacts with the system -- which is to say -- in a "role". For example, as "curator", "contributor", etc.
Furthermore, creating a separation between roles (granted to users and groups) and permissions or privileges (conveyed by those roles) allows for changes in policy to occur without changing repository data, which seems like a good thing in general.
Terms
A role type defines a categorical role -- e.g., Curator, Editor, or Viewer.
- A role type is an instance of the
RoleTypeclass. - Role types are independent (not hierarchical or related by some kind of inheritance).
- Each role type defines the
...
- permissions it will convey when asserted through a role assignment.
A role expresses a role assertion
- A role is an instance of the
Roleclass, havingrole_type,agent, andscopeattributes. - The association of a role with an object asserts that an agent (i.e., a person or group) "has" that type of role on the object within a scope that defines the application of the assertion, i.e., its translation into permissions.
- A role is "granted" when an association is made between a role and a repository object.
- A role is "revoked" when as association between a role and a repository object is removed (deleted).
The scope of a role assertion defines the object(s) to which its privileges apply.
- In resource scope, the role applies directly to the object which it is associated. This is the default scope when a role is granted.
- In policy scope the role applies indirectly to the objects governed by (via a policy relationship) the object with which the role is associated. In the Hydra context, policy scope makes sense only on AdminPolicy objects or other administrative objects that enforce control over other objects.
An agent is a entity (person or group) to whom a role is "granted".
- A Person agent (foaf:Person) represents an individual user of the system.
- A Group agent (foaf:Group) represents a set of (zero or more) users.
- A user is represented by one Person agent and one or more Group agents (everyone is a member of the "public" group).
Role Types
Role types are intended to reflect concepts of repository usage by humans. Therefore the rights shown below are defined in terms of what an agent granted a role of that type should expect to be able to do (within scope). See permissions for more detail.
| Role | Rights |
|---|---|
| Viewer | Can read metadata and download metadata and derivative files |
| Downloader | Includes Viewer rights, plus can download the original file ("content" datastream) of a Component, Target or Attachment |
| Contributor | Includes Viewer rights, plus can add "subsidiary" objects (e.g, an Item is subsidiary to a Collection, a Component is subsidiary to an Item, etc.) |
| MetadataEditor | Includes Viewer rights, plus can edit descriptive metadata |
| Editor | Includes Contributor, Metadata Editor and Downloader rights, plus can edit content and structural metadata |
| Curator | Includes Editor rights, plus can set access controls (roles) |
Initial Roles on New Objects
Collection
The Curator role is granted in both policy and resource scopes to the Collection creator. In the DDR, the privilege to create a Collection is not controlled by role, but by membership in a special group.
Item, Component, Attachment, Target
- The Editor role is granted in resource scope to the object creator.
- If the object is not governed by a policy, then it should copy the roles granted to the "parent" object in resource scope.
| Anchor | ||||
|---|---|---|---|---|
|
Permissions
At the level of the application at which access control is enforced, roles must be translated into data that can be used to answer the question: Can user X take action Y on object Z? This data consists of permissions which are calculated based on role assignments.
Permission Definitions
| Permission | Rights |
|---|---|
| read | Can view descriptive metadata and download derivative files |
| download | Can download original file(s) |
| add_children | Can create/ingest "child" resources (e.g., Items in a Collection) |
| edit | Can edit descriptive metadata |
| replace | Can replace original file(s) |
| arrange | Can change structural metadata (e.g., ordering of resources) |
| grant | Can grant and revoke roles |
Mapping of Roles to Permissions
| Role | Permissions |
|---|---|
| Viewer | read |
| Downloader | read, download |
| Contributor | read, add_children |
| Metadata Editor | read, download, edit |
| Editor | read, download, add_children, edit, replace, arrange |
| Curator | read, download, add_children, edit, replace, arrange, grant |
How Effective Permissions Are Calculated
Consider:
- Object O has admin policy A
- User U has group agents G1, G2, and G3 and person agent P
Then:
User U's effective permissions on object O are (logically):
Permissions for roles granted to P on O in resource scope
OR
Permissions for roles granted to G1 on O in resource scope
OR
Permissions for roles granted to G2 on O in resource scope
OR
Permissions for roles granted to G3 on O in resource scope
OR
Permissions for roles granted to P on A in policy scope
OR
Permissions for roles granted to G1 on A in policy scope
OR
Permissions for roles granted to G2 on A in policy scope
OR
Permissions for roles granted to G3 on A in policy scope