Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0


Fedora Versions: 2.x - 3.3

Wiki Markup*Contributor:* matt.zumwalt \ [at\]



RubyFedora provides a set of Ruby gems for creating and managing objects in the Fedora Repository Architecture ( RubyFedora was created by, and is maintained by Mediashelf (


Fedora Versions: 2.2.x, 3.1

Wiki Markup*Contributor:* [Muradora Project|] \ [[Nishen Naidoo| ] \]

demo | download


Muradora is designed to be a turnkey web front-end for Fedora focusing on flexible access control (see DRAMA). It is being developed as part of the DRAMA project(now the Muradora Project). Muradora is built in Java using the Spring Framework (with Struts 2), and makes heavy use of AJAX technologies to provide a richer and more dynamic user interface.
Its functionality includes:

  • Browsing and Searching (full-text)
  • Self submission and publishing interface
  • Support for Shibboleth authentication
  • Tree view of user-defined collections (based on user's own RDF ontology)
  • Authorization based on XACML but with an easy intuitive access control GUI (no need for any raw XACML editing by the end user)
  • Flexible metadata (DC, MODS, etc...) input based on XForms standard (utilizing Orbeon XForm server side engine so no browser plugins are required).
  • Utilizing DRAMA middleware components (see below) for better management of policies and consistent access control across many GUIs talking to a single Fedora server


Status: Active

Fedora Versions: 2.2

Wiki Markup*Contributor:* [DRAMA Website|]'' \ [ Chi Nguyen\|FEDINFO:User__Chi \ ]

download | demo


The DRAMA project aims to re-factor Fedora authorization into middleware components that can be plugged on top of an existing Fedora (2.2) deployment. It offers the following features:

  • Extended XACML Engine: We extended the Sun XACML engine to utilize an XML database (DB XML from Oracle) for the policy stores. There is a web interfaces for the update and editing of the XACML policies in the database. For a given XACML request, the XACML PDP can now quickly query the database using XPATH to find the list applicable policies (<10ms to match and evaluate through a set of 10000 policies). Finally, XACML requests and responses can be sent as web services call to/from the PDP. These extensions to the XACML engine can be utilized by any XACML based application, not just Fedora.
  • XACML PEP for Fedora: We developed Axis handlers to intercept API-A and API-M calls between the client and Fedora to enforce authorization based on XACML policies. The handlers can intercept requests perform authorization on that as well as intercept the response from Fedora and enforce authorization policies on the response back to the client. For the REST interface of Fedora, we developed servlet filters to perform the same function. Both the Axis handlers and the servlet filters utilize the same instance of the XACML engine (see above) hence a single Fedora repository can now have a consistent access control regardless of how one access it. This allows a single Fedora repository to support multiple GUI interfaces.
  • Federated Authentication and Identity Management: We developed modules (DAR and ASM) that can be deployed with Fedora to enable Shibboleth (as well as local LDAP) authentication for any web GUI talking to a Fedora repository; all without the need to change any Fedora code.