Difference between revisions of "EPrints User Group 2015-01-13"
(→Requirements) |
|||
| (19 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== | ||
* Control access to EPrints, Documents | * Control access to EPrints, Documents | ||
* Control access based on: | * Control access based on: | ||
| − | ** User attributes e.g. signed-in via Shibboleth | + | ** User attributes (e.g. signed-in via Shibboleth) |
| − | ** 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=== |
| − | * | + | *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 Objects=== |
*ACL Authority | *ACL Authority | ||
| − | **Corresponds to a method of | + | **Corresponds to a method of authentication (e.g. Shibboleth, LDAP etc.) |
*ACL Role | *ACL Role | ||
| Line 42: | 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 | + | **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) | ||
| + | |||
| − | ==Summary Page citation style== | + | ===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)? | *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 | *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=== |
| + | *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 | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | ==The horrors (and the solutions)== | + | |
| + | ===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) | *The out-of-the-box document security is deep within EPrints (we learnt about doing some really cranky Perl-fu) | ||
| Line 68: | 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*... | ||
| − | |||
| − | |||
Latest revision as of 17:48, 12 January 2015
| Access Control Layer | ||
John Salter and John Beaman, University of Leeds
Contents
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)
