Skip to main content
Skip table of contents

Sign into OpenAthens with local authentication systems

Introduction

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 additional accounts as this is already being handled within your organisation.

Examples of local authentication systems include:

  • Microsoft ActiveDirectory, ADFS or Azure
  • IBM Tivoli
  • LDAP
  • NetIQ Access Manager
  • Novell Access Manager
  • OpenID Connect
  • Ping Federate
  • More

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.

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. If you need to allocate specific permission sets you will need to release an additional attribute containing that permission set name. Permission set names appear in the following format: 

 <organisation prefix>#<name> e.g. edu#staff

User journey when local authentication system is integrated with OpenAthens

The diagram below shows the basic user journey to a resource both with and without a local authentication system being integrated:


Help

We understand setting up new connections can be time-consuming, and administrators can run into difficulty setting these up themselves. As well as our service desk, we have consultancy services available to support customers setting up a new connection and your account manager will be happy to discuss options and prices with you.

Specific systems

Descriptions...

ADFS

Full name: Microsoft ActiveDirectory Federation Services
Type: Delegated (uses your login)
Description: Part of Microsoft’s ActiveDrectory, ADFS can create a 1:1 SAML connection with a ‘provider’ (in this case OpenAthens) and send ‘claims’ (attributes) about the user.

CAS

Full name: Aperio Client Access Server
Type: Delegated (uses your login)
Description: For version 5 and above. A version of the SAML connector optimised for Aperio CAS. https://www.apereo.org/projects/cas

LDAP

Full name: Local Directory Access Protocol
Type: Brokered (our login queries your directory)
Description: Used by ActiveDirectory and other LDAP servers since the 90s

OIDC

Full name: Open ID Connect
Type: Delegated (uses your login)
Description: Uses the popular OIDC protocol for a simpler connection to things like Google Workspace

SAML

Full name: Security Assertion Markup Language
Type: Delegated (uses your login)
Description: A generic SAML connector. Used for things such as Microsoft Azure, Google Workspace and any other standards compliant SAML 2 identity providers.

SirsiDynix

Full name: SirsiDynix
Type: Brokered (our login queries your directory)
Description: Requires the SirsiDynix Symphony API and connects to your instance.

API

Full name: Application Programming Interface
Type: Delegated (uses your login)
Description: When there isn’t a dedicated connector for your system, you can use this to create your own.

Evergreen ILS

Full name: Evergreen ILS
Type: Delegated (uses your login)
Description: Uses the API connector in conjunction with an OpenAthens module in Evergreen

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.