Page History

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

Required Features for first release

...

Timeline:

...

   - Initial Partial Release by OpenRepositories '09 (May 18‑21)
   - Final release by June 30, 2009

Overview

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

Tear out & replace FESL will run alongside existing Fedora code but will assume that the standard Fedora XACML component is turned off. In this context FESL will override the existing XACML implementation.  (Existing code has no comments, no test coverage, etc.)

FESL will use the Muradora code Use DRAMA Code as starting point and will be written with Jaas.

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 FESL approach is that an object can only belong ideally belongs to one collection for authoriztion purposes, but multiple collections for presentation purposesauthorization purposes, providing a simpler approach to policy interpretation. However, sample policy templates will be provided which show more complex examples with multiple parents for one object. FESL will look at an approach that allows an object to be assigned to a policy object in the policy repository using a special authorization predicate.

Authentication (AuthN)

• Support surrogate authentication and document how to do itProvide documentation on how a GUI can allow a user to authenticate and pass the credentials to the Fedora server.
• Support LDAP, AD and Tomcat-Users by refactoring the existing servlet filters to make them more user friendly.
• Implement authentication in a modular way (ie. via Jaas) so that participating organizations can write their own adapters (ie. Drupal integration)Use servlet filters to enforce access controls on all inbound requests, OpenID, etc.).

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.
• The Muradora preference is to store the Policy in a separate Policy store (XML database) for efficiency and simpler implementation. The issue for existing Fedora installations which store policies in collection and object datastreams will be addressed in the initial FSL release with migration documents.
• Support for the new REST API.Support use of Fedora Objects' POLICY datastream

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 AuthNUser Interface and REST API for editing policies on Objects, Datastreams, and Collections
• FESL will implement an approach which will store policies in Fedora as Policy objects, which can then be subscribed to by the appropriate objects.
• 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 Add collections to PDP vocab (already in Muradora)
• provide Provide pre-vetted and fully documented set of policy templates (sorta already done by DRAMA using templates provided by Muradora and UPEI)
• reserve some time & budget for hammering out use cases here, vetting templates, and documenting them
• document how to get policies into policy manager (DRAMA?)
• Provide and fully document API for Policy Manager
• Configure Muradora Configure DRAMA PDP to be aware of POLICY datastreams (???)  --  not absolutely 100% necessary --This will not be done as part stage 1)
• Plug plug & play install experience (+Fedora Commons, MediaShelf)
• Add coverage for REST API in DRAMA PDP & PEP (???)
• Comply comply with Fedora 3.x (DRAMA working on this)
• Bundle solution with Fedora and include it in the installer (+Fedora Commons)
• Test & Refine Install Experience (+MediaShelf ?)

Doesn't Cover:

• Policy API
• Policy UI Tool
• Allowing repository managers to find out what policies apply to a given Object, Datastream, or Collectionand UPEI)