...
| Info |
|---|
LEGACY DOCUMENT: The current version can be found at https://gitlab.oit.duke.edu/ddr/ddr-admin/-/wikis/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
...
...
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
...
...
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.
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.
| 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