EPrints User Group 2015-01-13

John Salter and John Beaman, University of Leeds

Intro

• Hello: we're John Salter and John Beaman from the University of Leeds.
• We've spent some time trying to write an Access Control system for EPrints. It's been a horror.
• One of our use-cases is for Research Data, but it could be used on other repository types.

Out of the box User Access Control

• EPrints (you all know what this is, right..?) has basic control at the document level - the 'security' field:
  • public (Open Access)
  • validuser (anyone who's got an account on that EPrints instance)
  • staffonly (Repository editors/admins)
• This doesn't cover the requirements for some repositories...

Requirements

• Control access to EPrints, Documents
• Control access based on:
  • User attributes (e.g. signed-in via Shibboleth)
  • Location / IP address (e.g. on-campus)
• Simple interface to assign restrictions

EPACL: EPrints Access Control Layer

Modular Design

• Doesn't overwrite any existing 'security' specified on documents.
• Will be available as a standard EPrints Plugin (EPM package) via the EPrints Bazaar
• ACL Authority modules governing different methods of Authorisation and Authentication (see later) can be developed separately
• These modules can simply be 'dropped in' to the existing framework as required

ACL Objects

• ACL Authority
  • Corresponds to a method of authorisation (e.g. Shibboleth, LDAP etc.)

• ACL Role
  • Authorised by an ACL Authority with zero or more 'filters' applied
  • Filters act as additional requirements (e.g. ACL_Authority='LDAP', Filter='dc=leeds.ac.uk')

• ACL Group
  • Each ACL Group consists of one or more ACL Roles
  • The ACL Roles are combined within an ACL Group by being 'OR'ed or 'AND'ed together
  • One or more ACL Groups are applied to EPrints data objects (e.g. eprints, documents)
  • The ACL Groups applied to EPrints data objects are 'OR'ed or 'AND'ed togther

Request vs User

• Two basic steps to authorise access - request and user
• First EPrints checks if the request has appropriate access rights
• If so, any additional user requirements are also checked
• If not, the request is denied (since the user's credentials are irrelevant at that point)

Dealing with rejection

• What happens when someone is denied access?
  • Document landing pages
  • Restricted summary pages
  • Contact details to request access?

Summary Page citation style

• How do we deal with rejected requests (i.e. what do we show)?
• We can define different citation styles depending on whether the request is allowed or denied
• 'Restricted' citations may be required (e.g. to satisfy the minimum metadata requirements of a DOI)

Document-level landing pages

• Born out of DOI requirements
• Individual documents may have their own DOI, so ideally need their own 'landing page'
• Document landing pages should contain at least the mandatory metadata fields if linked from a DOI

The horrors (and the solutions)

• The out-of-the-box document security is deep within EPrints (we learnt about doing some really cranky Perl-fu)
• Documents don't use the SummaryPage - again this is deep in the code (we learnt lots about Eprints Triggers)
• Apache 2.2 and 2.4 differ in the way they handle IP addresses (Seb did some patching of EPrints code - but this hasn't been released - may be in 3.3.13?)
• All sorts of crazy inheritance complexities
• EPrints doesn't use 'sessions' in the same way as most other web software. Sessions are only created when a user logs in (we think user accounts need to be automatically created - is this right? It would be useful for tracking re-use)
• EPrints documentation is *ahem* offering room for improvement */ahem*...

Homeless thoughts

• Summary Page citation style
• Access logging
• Login sources: login screen with multiple routes (tabs) / LDAP as additional route rather than default route
• Modular design
• Request vs User
• Describe ACL_Group, ACL_Role, ACL_Authority
• DOIs at Doc level = landing page citation style
• Objects and SubObjects
• Viewing (downloading for a document)