You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Table of Contents

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.)

... should spend some time thinking about combining collection-level policies when objects belong to multiple collections.

Authentication (AuthN)

  • Support surrogate authentication and document how to do it
  • Support LDAP and Tomcat-Users
  • Implement authentication in a modular way so that participating organizations can write their own adapters (ie. Drupal integration)
  • Use servlet filters to enforce access controls on all inbound requests

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.)
  • 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 AuthN
  • User Interface and REST API for editing policies on Objects, Datastreams, and Collections
  • 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 (already in Muradora)
  • provide pre-vetted set of policy templates (sorta already done by DRAMA 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?)
  • Configure DRAMA PDP to be aware of POLICY datastreams (???)  --  not absolutely 100% necessary --
  • plug & play install experience (Fedora Commons, MediaShelf)
  • Add coverage for REST API in DRAMA PDP & PEP (???)
  • 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 Collection
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels