Security - AtlasOfLivingAustralia/profile-hub Wiki

Profile Hub


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 is implemented by way of a custom annotation (src/java/ that is applied to the controller actions where authorisation is required, and a filter (grails-app/conf/ Whenever a request is made to the server, the filter:


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
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.