OpenAthens can usually be run independently of the IT team should you choose to do so. There are some things that the IT team need to be aware of though so that they do not cause problems by accident when they change settings or implement new policies. This page will provide a brief overview of OpenAthens aimed at the IT team, and the technical information they may need

OpenAthens overview

It's a single sign-on system that uses SAML to work with the kind of federated access the library use to provide access to online journals and databases to the end-users. Identities can be managed within a hosted platform, but there are options to devolve that to your systems if they are compatible. As it uses SAML, it can also be used to access enterprise applications.


OpenAthens administration and end-user access all occurs over https. If you are restricting secure traffic, you will need to allow certain hostnames. See: What are the hostnames I need to allow my users to connect to from within my network


Email generated by the system may come from either of these domains.

If your end-users get email via your own email servers, then bulk creation of accounts by the library may see hundreds or thousands of emails being sent to your domain over a short period of time. You may need to white-list domains, or ask the library to limit bulk creation to smaller batches.

Mandatory data fields

The mandatory fields on OpenAthens accounts are:

  • first name
  • last name
  • email address

The mandatory fields on Local accounts are: 

  • a unique identifier passed by your systems
  • a display name (can be the same as the ID)

The data OpenAthens passes to service providers about your users

  • Default: a pseudonymous unique identifier, a role (e.g. member), and identifiers for your organisation
  • All other user attributes are restricted by default but have options to release them should you want to