Output – FAR – Adding Shibboleth to DSpace With CASAK

Output Name: Output – FAR – Adding Shibboleth to DSpace With CASAK

Title: Adding Shibboleth to DSpace With CASAK
Number of pages or page numbers: webpage

Date Released: unknown

URI for Output: https://dspace.far-project.lse.ac.uk/casak-shib.html (report) for

patch – https://saffron.caret.cam.ac.uk/svn/projects/far/trunk/

Summary of contents:

CASAK is a patch for DSpace which allows container auth to be integrated into DSpace. It provides a number of mapping and filtering facilities to transform data provided by the container into a form suitable for DSpace. These facilities are generally inferior to those available within the SP, but for simple cases the configuration is perhaps simpler.

Configuring CASAK to use Shibboleth is therefore simpler than many use-cases of CASAK.

The approach used here contrasts with that used in MAMS in that CASAK is not Shibboleth specific, and has been designed to make a range of container auth solutions possible with CASAK. The purpose of this was to increase the long-term sustainability of the patch by extending its application to as broad a user-base as possible.

Output – FAR – LDAP server containing sample users with these attributes

Output Name: Output – FAR – LDAP server containing sample users with these attributes

Title: LDAP server containing sample users with these attributes
Number of pages or page numbers: webpage

Date Released: 29 June 2008

URI for Output: https://gabriel.lse.ac.uk/twiki/bin/view/Projects/FAR/FARProjectDemonstratorArchitecture

Summary of contents:

Technical description of the FAR Demonstrator Architecture.

Output – FAR – FAR attribute requirements report

Output Name: Output – FAR – FAR attribute requirements report

Title: FAR attribute requirements report
Number of pages or page numbers: webpage

Date Released: 19 August 2008

URI for Output:  https://gabriel.lse.ac.uk/twiki/bin/view/Projects/FAR/AttributeUseReport

Summary of contents:

  • Requirements for specific attributes to be used for Federated Access Management (FAM)-mediated access to repositories are not necessary because repository products use groups for access control already
  • It is recommended that group membership information is structured in attribute stores on a per-user basis (with a user object containing a list of groups of which the user is a member) as opposed to solely as a per-group basis (with a group object containing a list of members)
  • The use of groups for authorisation means that it should be possible for FAM to continue to be applicable with the introduction of new features to repository software

Output – The Depot – Service and Project Websites

Title: Depot websites providing a full range of supporting documentation

Date Released: June 2007

URI for Outputs:

http://depot.edina.ac.uk/FAQ/ and


Summary of contents:

FAQ section on the project website and ‘manage deposits’ section of the service website.

Additional information:


There’s a significant amount of overlap between the project and service websites for the Depot, and the repository itself, so I’ve just listed both websites here. The FAQ section is the main area where supporting documentation is provided on the project website along with the ‘manage deposits’ section of the repository service website.

Output – The Depot – UK Repository Junction

Title: UK Repository Junction

Date Released: June 2007

URI for Output: http://depot.edina.ac.uk/junction.html

Summary of contents:

‘UK Repository Junction’ is a re-direct service to ensure that content that comes within the remit of an existing institutional repository is correctly placed.

Additional information:

The service is essentially part of the functioning of the Depot service quality repository (separately listed as an output).


On testing the redirection using the example of the University of Bath which has it’s own repository, the junction worked correctly.

Output – The Depot – Service Quality Repository

Title: The Depot Service Quality Repository

Date Released: Approx November 2007

URI for Output: http://deposit.depot.edina.ac.uk/

Summary of contents:

“The purpose of the Depot is to enable all UK academics to share in the benefits of open access exposure for their research outputs. As part of JISC RepositoryNet, the Depot is provided as a national facility geared to support the policies of UK universities and national funding agencies towards Open Access, aiding policy development in advance of a comprehensive institutional archive network”

The Depot offers the following features:

  • a re-direct service, nicknamed UK Repository Junction, to ensure that content that comes within the remit of an existing institutional repository is correctly placed.
  • accepts deposit of e-prints from researchers at institutions that do not currently have an Institutional Repository (IR). The principal target is postprints, that is articles that have been peer-reviewed and accepted for publication.
  • as  institutional repositories (IRs) are established, the Depot will support the transfer of relevant content to help populate those new IRs.  Meantime, the Depot will act as a keep-safe, notifying  institutions when deposits are made.
  • an OAI-compliant interface, so, like other open access repositories, its contents is available for harvesting, with special attention being paid to ensure that it can searched through the Intute Search, another part of JISC RepositoryNet.

Additional information:


I created a Depot account and submitted a test item for the purposes of assessing the repository on the 27th November 2008. The was later removed. My observations following this are:

  • The repository browse functioned well and was responsive. The repository in general was working well.
  • When submitting an item, the submission page annoyingly scrolls to the top on opening hidden metadata fields (Firefox 3.0.4 , Mac OS X 10.5.5).
  • The submission process is lengthy.
  • No subject matches found for ‘jazz’, ‘journalism’ or ‘music’. Seems odd.
  • The process of adding a new version of an existing item is convoluted and tricky.  Similar for deletion – not intuiative.

The Depot repository would appear to match a large number of repository benefit and role categories, all of which are self evident. Feedback would be welcomed on these.

Project – EIDeR

Project Name: Enhanced ingest to digital e-research repositories (EIDeR)

Programme Name:Repositories and Preservation

Strand:Interoperability Demonstrators

JISC Project URI: http://www.jisc.ac.uk/whatwedo/programmes/programme_rep_pres/interoperabilitydemos/eider.aspx

Project URI: no URL available at present

Start Date:1 April 2008

End Date:1 March 2009

Governance:JISC integrated environment committee

Contact Name and Role: Karen Stanton, Russell Burke, Vijay Albuquerque (King’s College London)

Brief project description: EIDeR aims to develop a demonstrator that implements enhanced deposit and ingest for institutional repositories (IRs). The demonstrator will not be a production system however,
it will be implemented within a real-life repository environment at KCL, and the implementation will address genuine needs, in particular by reducing the need for manual intervention and providing a more streamlined deposit process.

Name of Trawler:Mahendra Mahey

Output:No Outputs available as yet
Suggested outputs might include:

  • Detailed scenarios and use cases for enhanced ingest
  • Examination of services and tools that may be used to support this functionality
  • Create a demonstrator integrating these services to implement the identified workflows
  • Evaluate the results of the project, and in particular the extent to which the available services and tools, and associated standards, support the requirements

Specific deliverables:

  • demonstrator system
  • case study
  • shorter report co-authored with the CRIG Support Team
  • e-Framework components, including detailed scenarios, SUMs, Service Expressions