Difference between revisions of "EPrints User Group 2015-01-13"

From EPrints Documentation
Jump to: navigation, search
(→‎Modular Design)
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
{{AccessControl}}
 
John Salter and John Beaman, University of Leeds
 
John Salter and John Beaman, University of Leeds
  
Line 5: Line 6:
 
* We've spent some time trying to write an Access Control system for EPrints. ''It's been a horror.''
 
* 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.
 
* 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==
 
==Out of the box User Access Control==
Line 12: Line 14:
 
** staffonly (Repository editors/admins)
 
** staffonly (Repository editors/admins)
 
* This doesn't cover the requirements for some repositories...
 
* This doesn't cover the requirements for some repositories...
 +
  
 
==Requirements==
 
==Requirements==
Line 19: Line 22:
 
** Location / IP address (e.g. on-campus)
 
** Location / IP address (e.g. on-campus)
 
* Simple interface to assign restrictions
 
* Simple interface to assign restrictions
 +
  
 
==EPACL: EPrints Access Control Layer==
 
==EPACL: EPrints Access Control Layer==
 +
 +
 
===Modular Design===
 
===Modular Design===
 
*Doesn't overwrite any existing 'security' specified on documents.
 
*Doesn't overwrite any existing 'security' specified on documents.
 
*Will be available as a standard EPrints Plugin (EPM package) via the EPrints Bazaar
 
*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
+
*ACL Authority modules governing different methods of Authentication (see later) can be developed separately
 
*These modules can simply be 'dropped in' to the existing framework as required
 
*These modules can simply be 'dropped in' to the existing framework as required
  
−
===Dealing with rejection===
 
−
* What happens when someone is denied access?
 
−
** Document landing pages
 
−
** Restricted summary pages
 
−
** Contact details to request access?
 
  
 
===ACL Objects===
 
===ACL Objects===
 
*ACL Authority
 
*ACL Authority
−
**Corresponds to a method of authorisation (e.g. Shibboleth, LDAP etc.)
+
**Corresponds to a method of authentication (e.g. Shibboleth, LDAP etc.)
  
 
*ACL Role
 
*ACL Role
Line 45: Line 46:
 
**The ACL Roles are combined within an ACL Group by being 'OR'ed or 'AND'ed together
 
**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)
 
**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
+
**The ACL Groups applied to EPrints data objects are 'OR'ed or 'AND'ed together
 +
 
 +
===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===
 
===Summary Page citation style===
Line 51: Line 66:
 
*We can define different citation styles depending on whether the request is allowed or denied
 
*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)
 
*'Restricted' citations may be required (e.g. to satisfy the minimum metadata requirements of a DOI)
 +
  
 
===Document-level landing pages===
 
===Document-level landing pages===
−
*Born out of DOI requirements
+
*Partly born out of DOI requirements
 
*Individual documents may have their own DOI, so ideally need their own 'landing page'
 
*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
 
*Document landing pages should contain at least the mandatory metadata fields if linked from a DOI
  
−
===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)
 
  
 
===The horrors (and the solutions)===
 
===The horrors (and the solutions)===
Line 71: Line 83:
 
*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 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*...
 
*EPrints documentation is *ahem* offering room for improvement */ahem*...
 +
  
 
==Homeless thoughts==
 
==Homeless thoughts==

Latest revision as of 17:48, 12 January 2015

Access Control Layer

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 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 authentication (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 together

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

  • Partly 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)
Retrieved from ‘https://wiki.eprints.org/w/index.php?title=EPrints_User_Group_2015-01-13&oldid=11101’