-
Notifications
You must be signed in to change notification settings - Fork 3
Security
Authentication is controlled via CAS URL pattern matching (see below for the patterns).
Due to limitations of the ala-cas-client library used to intercept HTTP requests and redirect where necessary to the login page, we cannot use true RESTful URL patterns and rely on the HTTP verb. Therefore, create, update and delete URLs all end with the verb. If in future the ala-cas-client library is updated to handle the HTTP verb, these URLs can simply be modified to remove the verb: no other changes should be necessary. All URLs are mapped with the appropriate HTTP verb as well as having the verb in the URL itself.
See URLMappings.groovy for URL patterns.
This is the URL pattern matching regex list to be used for CAS authentication in the profile hub:
/.*/update.*, /.*/create.*, /.*/delete.*, /user/.*, /audit/.*, /admin/*
Authorisation is implemented by way of a custom annotation (src/java/au.org.ala.profile.security.Secured) that is
applied to the controller actions where authorisation is required, and a filter (grails-app/conf/au.org.ala.profile.filter.AccessControlFilters).
Whenever a request is made to the server, the filter:
- intercepts the request
- finds the controller action method
- checks if it has the Secured annotation
- if the annotation's opusSpecific field is set:
- looks up the opus (all requests must have an opusId parameter. The parameter name can be overridden with the opusIdParam property of the annotation).
- checks if the user is an Admin or Editor for that opus
- checks the user's role:
- If the user is an ALA Admin, they are authorised for all requests
- If the action requires the ROLE_PROFILE_ADMIN role, the user must be in the Admin list for the opus
- If the action requires the ROLE_PROFILE_EDITOR role, the user must be in the Editors list for the ops
There are 5 roles: ALA_ADMIN, ADMIN, EDITOR, REVIEWER, USER. The level of access is as follows: ALA_ADMIN > ADMIN > EDITOR > REVIEWER > USER. I.e. an ALA_ADMIN can do everything an ADMIN can do, and an ADMIN can do everything that and EDITOR can do, etc.
| Action | Required Role | Notes |
|---|---|---|
| Create collection | ALA_ADMIN | |
| View collection | USER | |
| Edit Collection | ADMIN | |
| Delete Collection | ALA_ADMIN | |
| Add new Profile | EDITOR | |
| View Profile | USER | |
| Edit Profile | EDITOR | |
| Delete Profile | EDITOR | |
| Export to PDF/JSON | USER | |
| Create new Publication | ADMIN | |
| Add comments to profile | REVIEWER |
Roles are currently defined per-opus and only have permissions for that particular opus.
A collection be marked as 'private', which limits access only to users who have been explicitly given a role in that collection. I.e., if a collection is marked as private, then it will not be visible to a user who is not logged in, or to users who are logged in but have no role within that collection.
Services exposed by the Profile Service are categorised into two buckets: secured and public.
Secured services require an API Key and are intended to only be called by the Profile Hub.
Public services require no form of authentication.