Security - AtlasOfLivingAustralia/profile-hub GitHub Wiki

Profile Hub

Authentication

Authentication is controlled via CAS URL pattern matching (see below for the patterns).

Secured URL 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

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

Roles

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.

Private Collections

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.

Profile Service

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.