Requirements for Improved FSL

This document is a work in progress [Feb 2009].

Required Features for first release

Ideal Timeline: (Beta) Release by OpenRepositories '09 (May 18‑21)

Overview

Create a useful AuthN/AuthZ implementation for Fedora that can be bundled with Fedora and included in the installer.  It must lend itself to integration with any Fedora client application.

Tear out & replace existing XACML implementation.  (Existing code has no comments, no test coverage, etc.)

Use DRAMA Code as starting point.

Vocabulary (Policy Templates)

Provide pre-vetted set of policy templates for:
 

• ACTIONS: Read, Create, Edit, Delete, and "Change Permissions"
  • One vocabulary covers all equivalent methods in SOAP and REST APIs (ie. policies decide at a higher level who can edit a datastream, rather than saying who can call the modifyDatastream SOAP method)
• TARGETS: Collections, Objects, and Datastreams
• SUBJECTS: User & Group
  • Assign permissions by User or by Group, regardless of where user attributes are coming from (ie. LDAP, Shibboleth, OpenId, CAS, etc.)

A general design principle of the FSL approach is that an object can only belong to one collection for authorization purposes, but can be in multiple collections for presentation purposes.

Authentication (AuthN)

• Support surrogate authentication and document how to do it [This needs clarification.]

• Support LDAP, AD and Tomcat-Users by refactoring the existing servlet filters to make them more user friendly

• Implement authentication in a modular way so that participating organizations can write their own adapters (ie. Drupal integration) [This needs some additional information from Paul.]

Policy Manager / Authorization (AuthZ)

• Enforce policies at Datastream, Object and Collection level. (Rely on either RELS-EXT or Fedora's bundled RIsearch for evaluating collection memberships.) This is already supported in the Muradora AuthZ work by supporting the precedence rule, where the policy at at the lower level takes precedence over that at higher levels.

• Support use of Fedora Objects' POLICY datastream. [The Muradora preference is to store the Policy in a separate Policy store (XML database) for efficiency and simpler implementation.]

• Support for the new REST API.

General

• Keep the implementation stable & current
• Bundle solution with Fedora and include it in the installer
• Audit the Implementation for potential security flaws
• Support community innovation & allow people to completely replace the whole thing if they wish
• Ensure that there are points that allow for future development

Desirable Features (not required for first release)

• Support Shibboleth
• Support OpenID & OpenAuth
• Support Single Sign-on (SSO) - must be pluggable/overridable
• Allow for Custom AuthN
• Simple, intuitive, well documented vocabulary for controlling Read, Create, Edit, Delete, and "Change Permissions" for Collections, Objects, and Datastreams
• User interface & REST API for editing policies on Collections, Objects, and Datastreams
  • Allow repository managers to find out what policies apply to a given Object, Datastream, or Collection

Work Packages

In order to satisfy the Requirements for an initial release, the following work must be done.

• Add colections to PDP vocab
• Provide pre-vetted and fully documented set of policy templates (using templates provided by Muradora and UPEI
• Provide and fully document API for Policy Manager
• Configure Muradora PDP to be aware of POLICY datastreams (This will not be done as part stage 1)
• Plug & play install experience (+Fedora Commons, MediaShelf)
• Add coverage for REST API
• Comply with Fedora 3.x
• Bundle solution with Fedora and include it in the installer (+Fedora Commons)
• Test & Refine Install Experience (+MediaShelf and UPEI)