When Melissa, Kathleen and I started talking about an Islandora blog, it felt like the right time to try and write some simple summaries of key Islandora/archival concepts (things I wished I’d had early on). Hopefully, if nothing else, people will tell me if I’m wrong, and offer a better explanation.
I have a list of some topics for these, but if there is something you would like to see introduced or discussed, just drop me a line at email@example.com.
What is XACML?
XACML (pronounced Zac-Mull around here) stands for eXtensible Access Control Markup Language - it’s an access control policy language implemented in XML, part of the Fedora security framework, and lies at the heart of Islandora’s security model.
XACML documents are stored and enforced in one of two places - either at the root of the Fedora installation (called a repository-wide policy, because it will affect the whole repository) or at the object level (as a datastream). A XACML policy defines what can be created, read, updated, or deleted in any object in the Fedora repository, and by whom. As a side note, I was charmed to find out that Create Read Update and Delete functions are often referred to using the acronym CRUD. XACML policies can be written for any CRUD function, and for a role, a user, or even an IP (computer or server) address.
The repository-wide policy is the most basic level of Fedora security. No matter what your object-level XACML policies say, there will usually be some repository-wide (or “global”) policy in your Islandora installation describing and enforcing what access folk get to Fedora’s management functions (often called API-M, referring to the Application Programming Interface for Management) and Fedora’s access functions (API-A, or the Application Programming Interface for Access). No matter what your object-level policy says, if the repository-wide XACML policy disallows an action, it ain’t gonna happen. So, your global policy is usually the basic, minimal security that will have to be applied to all objects. XACML at the object level is written to further restrict access, and can’t be written to grant permissions that the global policy allows. TL;DR - your global policy is the minimum policy for all objects, your object-level policies refine and further restrict access.
As you can imagine, the ability to place policies at different levels of the repository can lead to some confusion - If policies are written at both the global and object level, you can create conflicts where security doesn’t behave exactly as you are expecting. So, it’s really important to plan and consider how your XACML policies will interact.
There’s also another challenge - people often want to restrict access at a mid-level (somewhere between one object or datastream and the whole freakin’ repository). For example, repository managers often want to lock-down editing in a collection to a handful of users, or need to lock-down a collection of parochially-licensed content so that it is only visible to institutional users.
To manage this common case in Islandora, we attach security policies to collection objects. After the collection or parent object has a XACML datastream, everything ingested into the collection picks up a copy of the XACML datastream attached to the collection object. Presto! - Identical XACML datastreams for all the objects!
I can tell you are riveted. Probably wondering: but what happens when I update the security policy at the collection level? Alas, this has no immediate effect on any object that is in that collection. After all, each object has it’s own special XACML datastream. As is so often the case with any powerful software, extreme flexibility can become a usability liability.
Friends don’t let Friends Hand-Edit XACML policies
Islandora tries to simplify the challenges associated with repository security through the XACML editor module (as well as the servlet filter and the Drupal permissions layer, but that’s another story). The impetus behind the XACML editor is to provide a point-and-click way of writing and updating XACML on single objects and collections, and to batch update policies in collections when they need to change. Islandora also forces Solr (the core search and discovery engine for the repository) to obey its XACML overlord. Basically, Islandora makes sure that users can’t accidently return results from the solr search index that they can’t actually access in the repository.
Back in 2010 there was no XACML editor, and we were all sad - If you’re implementing Islandora, use the XACML editor unless you a) have really complicated security requirements, b) are a masochist, c) want to get back at a particularly grumpy summer student by forcing them to filter through acres of XML by hand to edit role entries.
XACML is defined/ratified by the Organization for the Advancement of Structured Information Standards (OASIS) https://www.oasis-open.org/
OASIS publishes a guide/introduction to XACML: https://www.oasis-open.org/committees/download.php/2713/Brief_Introduction_to_XACML.html
Fedora published a Fedora XACML Policy Writing Guide with sample policies that can be used as a starting point. There are also default policies provided in the Fedora download.
Get the XACML Editor:
Islandora 7.x: GitHub (still in dev, but functional to try)