A Turnkey Fedora GUI Supporting Heterogeneous Metadata,

Federated Identity, And Flexible Access Control

Chi Nguyen, James Dalziel

RAMP Project

Macquarie University,

Sydney, Australia

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

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

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

Yet Another GUI?

• Why Fedora?scalableFOXML object modelwell-defined APIsmodular Designlarge communities of adopters and developers

• But another Fedora GUI?– flexible Access Control– federated Identity– heterogeneous metadata– multiple GUIs, single Fedora repository

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!

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.

DC XForms

MODSXML XForms

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

Features Beyond Muradora

• Extended XACML support

• New Fedora XACML Authorization Framework

• Shibboleth Support For Fedora

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

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.

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

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

Our Authorization Pattern

Interceptor pattern

Repository

1. Request

AuthorizationInterceptor

2. Is the operation allowed?If yes proceed

3. Modify repositoryresponse to conformto authz policies

4. Response

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

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)

“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?

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.

DAR + ASM

DAR + ASM

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

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

Easy Install DVD Requirements

If run from DVD: lots and lots memory (at least 1.5GB)!

If run from system hard disk then > 1.5GB of memory > 1.5GHz CPU An IP address and corresponding fully qualified

DNS name.

Licensing

All our software are freely available under Apache 2 open source license.

All dependent components are freely available under various open source licenses.

Muradora Developers

Nishen Naidoo Cuong Hoang Damien Chen Markus Troescher (left recently) Chi Nguyen

{nishen, cuong, dchen, chi}@melcoe.mq.edu.au

Further Information

Muradora download and wiki

http://www.muradora.org

Muradora demonstration

http://demo.muradora.org