1 / 32

A Turnkey Fedora GUI Supporting Heterogeneous Metadata, Federated Identity,

A Turnkey Fedora GUI Supporting Heterogeneous Metadata, Federated Identity, And Flexible Access Control. Talk Outline. Our Goals Muradora Features Flexible Access Control Metadata management Multiple GUIs, Single Fedora Instance Licensing Features Beyond Muradora

kevina
Download Presentation

A Turnkey Fedora GUI Supporting Heterogeneous Metadata, Federated Identity,

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

  6. 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!

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

  8. DC XForms

  9. MODSXML XForms

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

  11. Features Beyond Muradora • Extended XACML support • New Fedora XACML Authorization Framework • Shibboleth Support For Fedora

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

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

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

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

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

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

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

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

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

  21. DAR + ASM

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

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

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

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

  26. Muradora Developers • Nishen Naidoo • Cuong Hoang • Damien Chen • Markus Troescher (left recently) • Chi Nguyen {nishen, cuong, dchen, chi}@melcoe.mq.edu.au

  27. Further Information Muradora download and wiki http://www.muradora.org Muradora demonstration http://demo.muradora.org

More Related