Access Control with Muradora

Muradora utilizes the XACML PDP engine (melcoe-pdp) and XACML-PEP (melcoe-pep, ie. the authorization layer which sits in-front of Fedora) to give end users the ability to control accesses to their digital objects. Importantly, this feature is provided via a GUI that hides the complexity of XACML from the end users, while still allowing them a high degree of flexibility in specifying the criteria on which access restrictions are made.

Brief XACML Introduction

Generic Actions

It should be noted that while there are multiple actions that are available to the user, many of these actions ultimately boil down to a small set of generic actions. An example is the "search" and "browse" functions which can be equated to performing a "read" on a particular resource.

An important motivation behind the use of XACML is that policies should be expressed in these generic actions so that they can be reuse and inter-operate across a set of heterogeneous applications. For that reason, we have abstract all the operations to a generic set consisting of: "create, read, update, delete, publish, admin". This action vocabulary can be extended should the need arises. The use of a generic set of actions also helps us in our design of a simple access control GUI.

In terms of Fedora, these actions are then mapped to the respective Fedora-specific operations to ensure a consistent access control irrespective of how the users access Fedora; either via Muradora or directly via one of its interfaces such as the API-A, API-M, or REST interfaces.

The meaning of these actions when applied to a particular resource (such as collection, object, or datastream) are explained in the table below. Hopefully, their meanings are quite intuitive. Not all actions will be available to all resources since those combinations do not make sense.