Table of Contents

  1. Introduction
  2. Injecting Arbitrary User Attributes

1 Introduction

This document collects technical notes on how to supply user attributes for evaluation of Fedora's XACML authorization policies.

For a practical introduction to using Tomcat authentication/authorization mechanisms for Fedora, see the Section 4 of the document Securing Your Fedora Repository. The current document is a technical appendix to that section.

2 Injecting Arbitrary User Attributes

Fedora 2.1 provides a mechanism to include user attributes from arbitrary source(s), and merge them with attributes provided by Tomcat realms or login modules. The Fedora code looks for a request attribute whose name equals the string constant fedora.server.Context.FEDORA_AUX_SUBJECT_ATTRIBUTES. A request attribute found under that name is taken as a Map, mapping names to values, and so giving additional user subject attributes. Currently, name must be a String and this is unlikely to change. Value must also be a String, and later this might be relaxed to include String[], to allow attributes with multiple values. Other types of value are not serviced. The effect within Fedora of having a key => value pair "a" => "b" in the Map is the same as having a Tomcat role "a=b" provided by a realm or login module, with the exception that the effect of having the same attribute key defined both places is undefined. (That is, don't do it. :)

So, e.g., a servlet filter need only create the map and populate it, and put it into the http servlet request as attribute named fedora.server.Context.FEDORA_AUX_SUBJECT_ATTRIBUTES. Fedora will then look for it, and use the attributes in xacml authorization. This services any subject attribute source, and remains source-neutral, i.e., you could use it to implement Shibboleth, but it doesn't favor Shibboleth.

If doing this, it would be best to isolate your interface code to be independent both of being in a servlet filter and also of interacting with the Map. This is so you could later refactor the code as a JAAS login module if needed. That would allow you to optionally authenticate as well, and also make the attributes available to security checks by Tomcat, i.e., through web.xml. You may not end up doing that, but the way you code now could speed that up.

This means of introducing arbitrary attributes has been tested by another developer successfully, but not by Fedora core developers.