A Turnkey Fedora GUI

1

• A Turnkey Fedora GUI
• Supporting Heterogeneous Metadata,
• Federated Identity,
• And Flexible Access Control

Chi Nguyen, James Dalziel RAMP Project Macquarie University, Sydney, Australia
2
Talk Outline

• Our Goals
• Muradora Features
• Flexible Access Control
• Metadata management
• Multiple GUIs, Single Fedora Instance
• Licensing
• Features Beyond Muradora
• Extended XACML support
• New Fedora framework for access control
• Federated identity support
• Muradora Live DVD
• Further Information

3
The RAMP Project

• Systemic Infrastructure Initiative
• Meta Access Management System (MAMS)
• till the end of 2008
• authentication, authorization, search services,
  metadata management
• Research Activityflow and Middleware Priorities
  (RAMP)
• also to 2008
• RAMS people oriented workflows for research
• DRAMA open standard auth/z implementations for
  protected repositories

4
Project Goals

• Collaboration preservation
• access search across institutional protected
  repositories
• easy to use and maintain access control little
  to no sysadmin intervention
• provide facility for the digitization of research
  outputs
• changing access control requirements with time

5
Current Status of Most Repositories

• Embedded (and often proprietary) authorization.
• Access control criteria are fixed
• Federated access not possible
• Vendor lock-in
• All of the above are real obstacles to research
  collaborations and preservation of outputs

6
Yet Another GUI?

• Why Fedora?
• scalable
• FOXML object model
• well-defined APIs
• modular Design
• large communities of adopters and developers
• But another Fedora GUI?
• flexible Access Control
• federated Identity
• heterogeneous metadata
• multiple GUIs, single Fedora repository

7
Muradora Flexible Access Control

• Leverage our new architecture for Fedora access
  control (more later).
• Simple yet flexible access control GUI for end
  user
• Intuitive hierarchical policies
• No end-user exposure to raw policy files.
• Access control criteria are NOT fixed!

8
(No Transcript)
9
(No Transcript)
10
(No Transcript)
11
(No Transcript)
12
Metadata Supports

• Wide repository use cases ? many different
  metadata formats
• Fedora does not enforce any metadata format!
• only DC is required
• GUI to handle metadata input and validation
• if metadata input logic is deeply embedded in GUI
  ? code rewrite of GUI for new metadata supports
• Solution XForms
• W3C standard
• Better form input and validation experience for
  the user
• Can handle complex metadata schemas
• Reusable
• Modular/pluggable GUI framework.

13
(No Transcript)
14
DC XForms
15
MODSXML XForms
16
Multiple GUIs with One Fedora

• Fedora scalability ideal for Institutional
  Repository
• An IR will require many GUI facets for
  different purposes
• Auth/Z (including Shibboleth) must be enforced on
  the server (Fedora) side
• GUI should be easily customizable to cater for
  many different use cases

17
Features Beyond Muradora

• Extended XACML support
• New Fedora XACML Authorization Framework
• Shibboleth Support For Fedora

18
What is XACML?

• XACML standard
• Policies in XML files external to the application
• Policies apply across heterogeneous applications
• Changing requirements for access control do not
  require code modifications
• Better auditing of overall access control
• Current implementation
• Sun XACML Engine implements v1.1 of the standard

19
XACML Adoption Roadblocks

• Policy consistency and verification?
• Policy editor
• Difficult XACML is too flexible
• Maturity of Sun reference implementation
• Policy mangement query, create, update, and
  delete of policies
• Not XACML 2 Hierarchichal resource profile
• Lack of XACML vocabulary for repositories.

20
Muradora Extended XACML Support

• Better policy management for SUN XACML engine
• DB XML database (from Oracle) for policy store
  and (extremely fast) queries.
• Web service interface to manage the policy
  stores.
• New hierarchical policy combination algorithm ?
  useful for applications which requires
  hierarchical access control of resources.
• Web service interface for XACML requests and
  responses

21
Fedora Native XACML Implementation

• XACML introduced in version Fedora 2.1.1
• Management of XACML policies filesystem
• Editing/creating of XACML policies by hand
• Embedded XACML enforcement (PEP)?
• No hierarchical enforcement (ie. cannot set a
  uniform access control at the collection
  level).
• No way to see what is the current access control
  for a given object.
• Changing a policy can have unintended
  side-effects.
• Intended for sysadmin rather than end-users

22
Our Authorization Pattern
Interceptor pattern
Authorization Interceptor
1. Request
2. Is the operation allowed? If yes proceed
Repository
3. Modify repository response to conform to authz
policies
4. Response
23
Advantages of Interceptor Pattern

• Modular, and pluggable authorization module
• No modification of repository code? no need to
  maintain our own special version of Fedora
• Repository can focus on its core functionality

24
AuthZ Implementation

• Code name melcoe-pep
• Interceptor pattern implementation
• Web services AXIS handlers
• REST interface servlet filters
• Both REST servlet filters and AXIS handlers
  generates the required XACML requests and send
  them to a common PDP.
• Uniform Authz for both REST, and web service
  interfaces to Fedora (future inc. Fedoragsearch
  OAI-PMH and SRU/SRW)?

25
Shibbolizing Fedora

• Roadblocks
• Shibboleth is only for web resources, ie.
  Browser-Post profile of SAML standard
• Fedora relies on a (web) GUI making web service
  calls to it.
• Not possible to shibbolize all the GUIs talking
  to the one Fedora server.
• No current free and open implementation of SAML
  exists for web services.
• How do we do shibboleth for web-service based
  products like Fedora?

26
DAR ASM

• Single-Sign-On for GUI web interfaces that use
  authenticated web services and HTTP
  communications to a back-end server, eg. Fedora
• First step towards consistent auth/z for
  multiple web GUIs talking to a single server
  architecture.

27
DAR ASM
28
DAR ASM

• Provide supports for federated identities
• DAR and ASM are pluggable modules
• No code modification of Fedora!
• The GUI does not need to be shibbolized
• Many GUIs for a single repository
• Portal GUI talking to many repositories
• Consistent unique federated opaque identifiers
  for users

29
Easy Install DVD

• Many separate components by design plug ability,
  reuse, flexibility
• However
• complex to set up
• technologies are new (and changing!)
• complaints from early trials
• Easy install DVD
• Allows users to quickly learn about the software
  by running it directly from the DVD.
• Easily installation to system hard disk

30
Easy Install DVD Requirements

• If run from DVD lots and lots memory (at least
  1.5GB)!
• If run from system hard disk then
• gt 1.5GB of memory
• gt 1.5GHz CPU
• An IP address and corresponding fully qualified
  DNS name.

31
Licensing

• All our software are freely available under
  Apache 2 open source license.
• All dependent components are freely available
  under various open source licenses.

32
Muradora Developers

• Nishen Naidoo
• Cuong Hoang
• Damien Chen
• Markus Troescher (left recently)
• Chi Nguyen
• nishen, cuong, dchen, chi_at_melcoe.mq.edu.au

33
Further Information

• Muradora download and wiki
• http//www.muradora.org
• Muradora demonstration
• http//demo.muradora.org