Table of Contents

  1. 1 Introduction
  2. 2 tomcat-users (memory realm/loginmodule) conventions
  3. 3 JAAS Edits
  4. 4 LDAP Edits
  5. 5 Arbitrary User Attributes

1 Introduction

For a practical introduction to using Tomcat authentication for Fedora, see the Section 4 of the document Securing Your Fedora Repository. The current document is a technical follow-on to that section. The basics under Tomcat is covered in http://tomcat.apache.org/tomcat-5.0-doc/realm-howto.html A few of the Tomcat source files were edited and compiled for use with Fedora.

2 Memory Realm / Login Module (tomcat-users.xml) Conventions

3 JAAS Edits

4 LDAP Edits

5 Arbitrary User Attributes (e.g., for Shibboleth)

Fedora 2.1b includes a string constant fedora.server.Context.FEDORA_AUX_SUBJECT_ATTRIBUTES and looks for an http servlet request attribute named after that constant. The Fedora code now takes a request attribute found under that name, as a Map giving name => values of subject attributes. Currently, name must be a String and this is unlikely to change. Value must 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", with the exception that the effect of having the same attribute key defined both places is right now undefined. (That is, don't do it. :)

So your servlet filter needs 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 link in 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 into 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.