Adventures in setting up access controls in a Fedora Commons repository

Quattro Pro for DOS: an obsolete format at last?

We have been evaluating the use of the latest Fedora Commons, version 3.6.2, as a test repository.  Having followed the straightforward installation process we were left with a repository with one preconfigured user – fedoraAdmin. 

There are two APIs – API-A for access and API-M for management.  For our test instance API-A was configured on installation to require a log in, but it can be configured to require no log in.  It appeared that whilst the REST API for API-A was restricted, the SOAP API for API-A was not, this was corrected by using the example policy, below.  Investigations of how to configure multiple users are also detailed.

Access controls/users

Fedora Commons security makes use of XACML, a verbose access control policy language written in XML.  It is possible to define a user type/profile in XACML and create users with that profile in fedora-users.xml.  A policy writing guide and vocabulary are available.

XACML will soon be/has been superseded by the Fedora Security Layer (FeSL), which uses “an alternative XACML policy enforcement engine”.  FeSL authentication is the default authentication mechanism, however, FeSL authorisation is currently marked experimental.

The Fedora XACML Policy Writing Guide states “It should be noted that to help users who do not wish to learn native XACML, a Policy Authoring Client is currently under development that will provide an easy graphical user interface for creating XACML policies for Fedora.”  However, when searching for the “Policy Authoring Client” I found an unanswered question sent to the Fedora Commons development mailing list querying its status, in April 2007, so I am unsure of where to find it.

An example policy that restricts API-A to users with “administrator” or “professor” roles can be downloaded from deny-apia-if-not-tomcat-role.xml.  A change of the type from “professor” to “apiauser”, and adding a user in fedora-users.xml with that fedoraRole value will allow access to API-A for that user.

There may well be other aspects of the repository that need securing, too.

Other configuration issues

We chose to configure Fedora Commons to be reverse proxied through an Apache web server.  This leads to some issues about configuring the “Base URL” for the repository.  Only the IP address/hostname can be set, the externally facing http transport type and port cannot be configured in the Fedora Commons settings.  This required a small kludge where Tomcat was configured to run on port 80.

If there are any corrections to the above, questions, or suggestions of other ways to configure the policies (e.g. a GUI) please do comment!


Leave a Reply

Join the conversation