Role Based Access Control

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 RoleType class.

• 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 Role class, having role_type, agent, and scope attributes.

• 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 (persisted) 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 to the object which it is associated and is not inherited by any child objects. This is the default scope when a role is granted.

• In policy scope the role applies indirectly (by inheritance) to the objects governed by the object with which the role is associated. In a Hydra context, policy scope makes sense only on AdminPolicy objects (i.e., Collections) or other administrative objects (of which there are currently none) that enforce control over other objects.

An agent is a entity (person or group) to whom a role is granted.

• A Person agent represents an individual user of the system. Currently a person agent is denoted by a username (e.g., admin@duke.edu)

• A Group agent represents a set of users. Currently a group agent is denoted by the group name. Static group memberships are maintained in Grouper; other groups memberships are determined at runtime based on user attributes (such as affiliation) or authentication status (e.g., the "registered" group represents authenticated users of the application).

• 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.

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.

• The MetadataEditor role is granted in policy scope to the Metadata Managers Group (membership managed in Grouper).

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.

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

Mapping of Roles to Permissions

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}