The OpenAthens SP Server software does not offer any authorisation functionality.
The provided AtacamaAuthFilter just requires a valid-user and this condition will be met as long as the 'authentication receive' flow exports a 'subject' parameter. This section will outline how additional authorisation checks may be enforced.
How attributes are written
The AtacamaBaseFilter will intercept any responses sent from an Identity Provider. If the response is valid this filter will write any attributes to the users' session along with the special attribute subject which will contain the subject value exported from the authentication receiver flow. The actual value of subject will depend on the underlying configuration and the responding Identity Provider. Then when a user tries to access a protected page the AtacamaAuthFilter will be called, if the session contains a subject (it's not empty or null) the user will be granted access. If the session does not contain the subject attribute the authentication request process will be invoked.
How attributes are stored
As attributes can be multi-valued, the attribute name is stored in the session as a String and the associated values are stored as a List<String>. E.g:
Defining the authorisation policy
In a case where the consideration is whether the end-user is from a site that has purchased a licence we need a way of identifying the users' site for comparison.
The attribute to use for this is
scopedAffiliation is made up of two parts, e.g.
role@scope. In this use-case the scope needs to be extracted (the role section could be used for greater granularity such as telling 'staff' from 'student' or 'alum'. There are a small number of possible values).
Implementing an authorisation filter
Users from the organisation with the scope
examplescope.com would get through.
Edit the web.xml to include our new Authorisation Filter, then add a filter-mapping after the filter-mapping which invokes the AtacamaAuthFilter. Please see the below example fro further clarification:
- User attempts access
- User is not yet authenticated so the
AtacamaAuthFilterredirects the user to their Identity Provider's login page
- The user logs in and is returned
AtacamaBaseFilterintercepts the Identity Provider's response and, assuming there are no problems, the subject and user attributes are written to the user session
AtacamaAuthFilteris called again but this time as the subject variable is in the session, control is passed to our authorisation filter
- If the user is from an organisation with an authorised scope the underlying content will be display to the user, else an 'unauthorised' response will be returned.