OpenAthens LA support ended on 31 March 2020


Skip to end of metadata
Go to start of metadata

This section will cover the configuration of OpenAthens LA through the administration interface and is aimed at the library based user.

The first thing to understand is the landscape of federated access management and what part LA plays. From this understanding, the purpose of the available functions becomes much clearer.

Federated access management basics

Federated access management splits authentication (checking who someone is) and authorisation (what they can access) between the two parties best able to do each. Authentication is carried out by the 'Identity Provider' (IdP), which is the organisation that the user belongs to - they know best if a user is one of theirs or not. The authorisation is carried out by the 'Service Provider' (SP) who know best which organisations can access which parts of their service.

The SP makes their authorisation decision based on the attributes that are sent to them from the IdP about the user who is attempting access and that in brief is what OpenAthens LA is designed to do: pass attributes to service providers.

These attributes will say usually include a minimum of an identifier plus the role and organisation - these would typically looks something like:

The first is called a targetedID and, whilst consistent for a user when they return to the same SP, each different SP sees a different ID for the same user.

The second is the user's 'role' @ 'organisation identifier'. This organisation identifier is called a 'scope' and is a domain that you own. The role part usually has defined names within a federation, typically including values such as member, staff, student, faculty, alum.

Other attributes can be passed if the SP needs to be able to tell if a user is, say, a medical student so that they can be shown different content.

What OpenAthens LA does, is send attributes to service providers, and most of the configuration options you can use are centred around that goal.

Categories, attributes and release

The three main elements that OpenAthens LA uses to decide which attributes to send to which service providers are categories, attributes and release policy.


These are how you organise and segment your users. They are used to assign general attributes such as roles, and also in the generation of statistics. 


These are the things you can say about your users. They might be general such as role, or user specific such as name or email.

Release policy

If the attributes are the things you can say about your users, release policies control who you can say it to. Some attributes will be ok to send to any service provider (e.g. targeted ID or role), but others would only be sent to very specific ones (e.g. email address).

OpenAthens LA will not respond to all requests from service providers, only those in connected federations.

Other functions

OpenAthens LA has many options and functions which are explained within this section of the documentation.

If this is your first time here, you should start with the Familiarisation with the administration console page and follow the suggested path through the features. If you are interested in a particular function, the list below may be helpful as may the side navigation or search function in the header bar.

  • No labels