It is possible to devolve the username and password part of OpenAthens to a local authentication system. From the users' perspective, they will not need to remember additional OpenAthens credentials, instead using existing ones such as their network login. From an administrator's perspective, you would not need to create or manage (e.g. password resets) additional accounts as this is already being handled within your organisation.

Examples of local authentication systems include:

  • ADFS (Active Directory Federation Server)
  • Azure
  • G-Suite (formerly Google Apps)
  • LDAP or ActiveDirectory
  • Ping Federate
  • SirsiDynix

How do my local authentication system and OpenAthens work together?

OpenAthens still takes care of things like the access to resources, federations, permission set management and statistics - these remain under the control of the library - but the usernames and passwords are handed off to your local system where your IT team is already managing user accounts.

You should use at least two factor authentication for your local users (e.g. username and password, barcode and pin).

Permission set considerations

You should think about your existing subscriptions and decide whether all users should inherit your default permission set, or if you need to allocate specific permission sets to different groups of users.

User journey when local authentication system is integrated with OpenAthens

The diagram below shows the user journey to a resource when a local authentication system has been integrated with OpenAthens:

How to integrate your local authentication system with OpenAthens

Using LDAP (including ActiveDirectory) as the local authentication system

Using ADFS as the local authentication system

Using generic SAML (e.g. OpenAthens LA, G Suite, Microsoft Azure, CAS) as the local authentication system

Using SirsiDynix as the local authentication system

Using the OpenAthens API connector with your portal