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

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

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

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 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 Authorization Interceptor 2. Is the operation allowed? If yes proceed 3. Modify repository response to conform to 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

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,

Further Information Muradora download and wiki Muradora demonstration