How to set up and manage LibAuth authentication in LibApps

LibAuth allows you to securely integrate your institution's authentication system with LibApps. This not only provides library staff with an additional option for logging into LibApps, but it also allows you to require patron authentication in your Springy tools.

  • LibCal: require patrons to authenticate before registering for calendar events, scheduling appointments, and/or booking your spaces & equipment.
  • LibGuides CMS: restrict access to a guide, group, or your entire site to authenticated users only.
  • LibGuides E-Reserves: require patrons to authenticate before viewing content for a specific course, restrict access to your entire e-reserves system to authenticated users only.
  • LibApps: allow users to log into LibApps using your institution's authentication system, as an alternative to using their LibApps username & password.

This springboard is intended for LibApps Admin users who are interested in setting up LibAuth for the first time or managing their existing LibAuth configurations. You'll learn more about added and configuring each supported authentication system, as well as how to use your LibAuth configurations throughout LibApps.

Your mileage may vary: we understand that everyone's authentication system may be set up differently than what's considered standard. Because we can't anticipate all of the possible setup variations, your mileage may vary from what's covered in these guides. Please work closely with your IT staff and don't hesitate to contact Springy Support if you need any help!

SAML, Shibboleth, & ADFS configurations

Security Assertion Markup Language (SAML), Shibboleth, & Active Directory Federation Service (ADFS) are by far the easiest configurations to setup and maintain, especially if you belong to a federation such as InCommon or the UK Federation (of which Springshare is a member). These systems also support the use of group permissions for fine tuning your authentication (i.e. restricting access to specific types of users, such as students or faculty).

  • Do you belong to InCommon or UK Federation? If so, you can take advantage of our express setup -- when prompted, all you need to do is select your institution from the member list.
  • If your site does not automatically add InCommon service providers, your IT staff must add Springshare as an authorized service provider using the appropriate Entity ID for your region. (You will find a link to the Entity ID at the top of the Configuration tab in your SAML configuration's settings.)
  • If you are using SAML via Okta to log into LibApps, please note that LibApps cannot read cookies written by Okta. As a result, LibApps would not know whether or not a user was already logged in (i.e. users will still need to click the link to your LibAuth configuration on your LibApps login page).
  • ​If you are using OpenAthens, it is possible to set it up manually using SAML. However, please note that Springshare is unable to provide support for OpenAthens configurations.

InCommon or UK Federation members

Other SAML systems

Shibboleth

ADFS

[Return to top]


CAS configurations

Similar to SAML, Central Authentication Services (CAS) is a cinch to set up and also supports the use of groups, as well. LibAuth currently supports the CAS 2.0 and 3.0 protocols. When setting up your configuration, LibAuth will give you the appropriate provider URL for your region. Before you can begin using your CAS configuration, your IT staff must add Springshare as an authorized service provider using this URL.

Learn more

[Return to top]


LDAP configurations

Although Lightweight Directory Access Protocol (LDAP) is supported, it's far more complicated to set up compared to SAML, Shibboleth, ADFS, or CAS. If your institution has those services available, we recommend using them instead. Please note that, unlike SAML and CAS, group permissions are not supported with this method, either.

Before you can begin using LDAP, your IT staff must make sure that your LDAP server port (typically 389, 636, or 3269) is open to our server's IP address for your region (which you can find under the Configuration tab of your LDAP configuration settings).

When configured, users will be taken to a LibAuth login form to authenticate via your LDAP system. You will be able to customize parts of this page in your configuration's settings.

Learn more

[Return to top]


SIP2 configurations

If your ILS supports Standard Interchange Protocol v2 (SIP2), you can use this to allow patrons to sign in using their library cards and PINs. Groups are not supported with this method. Please note that, unlike SAML and CAS, group permissions are not supported with this method.

Before you can begin using SIP2, your IT staff must make sure that your SIP2 port (usually 6000, 6001, or 6002 depending upon your ILS) is open to our server's IP address for your region (which you can find under the Configuration tab of your SIP2 configuration settings).

When configured, users will be taken to a LibAuth login form to authenticate via your SIP2 system. You will be able to customize parts of this page in your configuration's settings.

Learn more

[Return to top]


Self-hosted configurations

Have you created your own custom authentication system? We can support that, too! Because these self-hosted systems are inherently customized, though, it may be more complicated to add these to LibAuth than CAS, SAML, or SIP2. Please note that, unlike SAML and CAS, group permissions are not supported with this method, either.

Before you can begin using your self-hosted configuration, check with your IT staff to ensure that your firewall allows access to the LibAuth server's IP address for your region (which you can find under the Configuration tab of your self-hosted configuration settings). In addition, your system will need to return a response in either JSON (recommended) or Text format.

When configured, users will be taken to a LibAuth login form to authenticate via your self-hosted system. You will be able to customize parts of this page in your configuration's settings.

Learn more

[Return to top]


SirsiDynix Symphony configurations

If the Symphony Web Services API is enabled for your SirsiDynix Symphony system, you can use it to authenticate via LibAuth (please consult Symphony documentation or support to enable the Web Services API in your instance of Symphony). Please note that, unlike SAML and CAS, group permissions are not supported with this method.

Before you begin using your Symphony configuration, you will need to obtain the URL for your Symphony API and your Symphony Client Identifier.

When configured, users will be taken to a LibAuth login form to authenticate via your Symphony system. You will be able to customize parts of this page in your configuration's settings.

Learn more

[Return to top]


OAuth 2 configurations

LibAuth supports authentication via an OAuth 2 application. One benefit of using OAuth 2 is that, like SAML and CAS, these systems also support the use of group permissions for fine tuning your authentication (i.e. restricting access to specific types of users, such as students or faculty).

Before you begin using your OAuth 2 configuration, please note that LibAuth supports the Access Code grant type for user logins. In addition, you will need to use the provided redirect URL for your region when setting up your OAuth 2 application. You can find the redirect URL under the Configuration tab of your OAuth 2 configuration settings.

Learn more

[Return to top]


Using LibAuth in your Springy tools

Once you've created and tested your LibAuth configuration, you can begin using it throughout your Springy tools. Below you'll find more info about where LibAuth integrations are available and how to use them.

LibApps

For most configuration types, you have the option of using LibAuth to log into your LibApps system. This option can be enabled directly in your LibAuth configuration's settings. For the login functionality to work:

  • You must release the correct email attribute to LibAuth from your authentication system.
  • Users must have a LibApps account in the system using the same email address that is being returned by the email attribute.

If a person's email addresses do not match, they can always update their LibApps account's email address on the My Account page. LibApps admins also have the ability to update email addresses from Admin > Manage Accounts (this has to be done via the LibApps dashboard -- not from each individual app).

LibCal

You can require patron authentication in various parts of LibCal, giving you the peace of mind that only valid patrons are able to use your services. It also helps ensure that you are recording accurate patron information, as well. If you use SAML, Shibboleth, ADFS, or CAS, you can also use groups to further restrict access to certain spaces, equipment, etc.

LibGuides

If you have LibGuides CMS, you can add LibAuth access rules to your system. These can be used to restrict access to individual guides, groups, or your entire site. This will require users to authenticate before accessing the restricted content. If you are using a SAML/Shibboleth/ADFS or CAS configuration, you can also apply any of your LibAuth group permissions to an access rule to further restrict access (i.e. a staff-only guide or group).

If you subscribe to the E-Reserves module, you can also require patron user authentication for viewing E-Reserves course content. This can apply this as a system-wide default, or simply enable LibAuth for individual courses. If supported by your type of LibAuth configuration, you can even use group permissions restrict access to certain courses to only certain groups of users.

[Return to top]

Related Springboards