-
Notifications
You must be signed in to change notification settings - Fork 29
Islandora XACML Editor
The Islandora XACML Editor (IXE) exists to grant users the ability to construct object level XACML policies easily and intuitively. These policies are stored as an XML datastream in the POLICY datastream. Currently, the Islandora XACML Editor implements the 1.0 specification of XACML which can be found in detail at http://www.oasisopen.org/committees/download.php/2406/oasis-xacml-1.0.pdf. A brief introduction to XACML itself is laid out at: https://www.oasis-open.org/committees/download.php/2713/Brief_Introduction_to_XACML.html. Relationship information for objects is stored in their RELS-EXT datastreams detailing the restrictions on the object itself. Datastream and MIME type restrictions are stored in the RELS-INT datastream. Both the RELS-EXT and RELS-INT use the Islandora ontology and implement islandora:isViewableByUser and islandora:isViewableByRole to identify these restrictions.
The most common use of object level policies is to restrict the ability to view the object in the repository view or in search results generated by Solr. This filtering is done by altering the collection query and the Solr search queries. To do the IXE module implements hooks provided by core Islandora. As of current, the Islandora XACML Editor deletes the collection query when enabled to filter out objects where restrictions apply. Development is planned to revise this; however, is not a top priority at present. Similarly, all Solr searches are appended with a filter query laying out the current user's name and roles to search against with the specified Solr fields. The IXE requires that Solr indexes the RELS-EXT, an example chunk to do this can be found at: https://github.com/discoverygarden/islandora_transforms/blob/master/RELS-EXT_to_solr.xslt.
The IXE configuration pages allows the user to enter defaults for users and roles selected and filters not allowed to be added as restrictions. Continuing, if the user does not want restrictions on datastreams and MIME types these can be turned off. Furthermore, the Solr RELS-EXT fields need to be configured such that the viewing restrictions work correctly. If the user has permission to place an XACML POLICY on an object the “Object Policy” tab will be present on the Manage tab of an object.
The IXE provides three types of restrictions that can be applied to objects. The object management section of the screen (shown above) is fairly self-explanatory. As the IXE is in its infant stages in Drupal 7 there may be some cases where Islandora itself does not fully check that the current user isn't restricted before executing some operations. If this is the case a 401 error will be displayed stating unauthorized access.
In detail the following Fedora API calls are restricted for management restrictions:
- addDatastream
- addDisseminator
- adminPing
- getDisseminatorHistory
- getNextPid
- ingest
- modifyDatastreamByReference
- modifyDatastreamByValue
- modifyDisseminator
- modifyObject
- purgeObject
- purgeDatastream
- purgeDisseminator
- setDatastreamState
- setDisseminatorState
- setDatastreamVersionable
- compareDatastreamChecksum
- serverShutdown
- serverStatus
- upload
- dsstate
- resolveDatastream
- reloadPolicies
Continuing, the object viewing restrictions fieldset is as described. As stated formerly, this will cause objects to not be visible in the repository view and search results.
The following Fedora API calls are restricted for viewing restrictions:
- The entire API-A tree of methods (https://wiki.duraspace.org/display/FEDORA34/API-A).
- getDatastreamHistory
- listObjectInResourceIndexResults
Finally, the DSID and MIME type restrictions fieldset allows the user to enter restrictions based upon datastream ids or MIME types. The only Fedora API that this rule restricts is that of getDatastreamDissemination. This blocks the content of this datastream from being accessed. This fieldset allows the user with the most customization in terms of the interface.
The DSID and MIME type textfields are powered by Drupal's built in autocomplete. DSIDs are autocompleted from the current object's datastreams, while MIME type pulls from the DS-COMPOSITE-MODEL of the object's content model. However, it is to be noted that you can add values not constrained within these autocomplete fields. The IXE is built such that the RELS-INT relationships only are written if the object currently has the specified datastream we are restricting. After the initial POLICY is applied, if a new datastream is ingested onto the object the POLICY is queried to ensure that these relationships are added to the RELS-INT.
The DSID and MIME type regular expression fields take advantage of the XACML specifications ability to provide matching on a more broad basis. XACML implements regular expressions in the form defined by the XML Schema (W3 Regex Guidelines). It is to be noted, that this should only be used by a very experienced user as this could completely lock all datastreams on an object.
The IXE does allow for batch updates of the POLICY datastream. This is done by implementing and invoking hooks (hook_islandora_xacml_editor_child_query). This drop down option will only be present on objects where this is possible. Core Islandora allows batch updating on “islandora:collectionCModel”s. Another thing to be noted is that when ingesting through the UI, if a parent object has a POLICY this POLICY will be applied to the child on ingest. Deletion of the POLICY datastream is currently facilitated through the “Manage” tab of an object.