Authentication Enhancements

Follow
These release notes describe functionality that may not have been released yet. To see when this functionality is planned to release, please review What's new and planned for ILLiad. Delivery timelines and projected functionality may change or may not ship.

Many authentication systems store information about patrons including credentials, access information, and profile attributes. ILLiad users want to take advantage of these central identity repositories, reducing the need to manage user data within ILLiad.  ILLiad will validate and update user information, verify access, and import relevant data to the user identity record with each login. This is a step toward separating patron data from the ILLiad system.

Features

  • Enhanced patron experience: Reduces the need for patrons to re-key information into ILLiad registration forms by leveraging existing data already known and validated by your institution
  • More accurate statistics and reporting: Frequently updated user data means more accurate demographic information as well as increased normalization of data 

Proposed Workflow

ILLiad will validate registering patrons with the external authentication system verifying access and importing relevant user information. At each login, ILLiad will validate credentials, verify access as well as update any relevant identity data.

Impact

  • ILLiad staff users will need to make decisions about what data to import and configure those data import choices
  • Local IT staff may need to be involved if any changes to the configuration of authentication systems are needed to support the new functionality

Feature Description

A new table (similar to the OpenURLMapping table) will allow staff to control how ILLiad uses the information passed from the remote authentication system. Options will exist to:

  • Map remote authentication user attribute fields to ILLiad User/UsersAll table fields (ex. Shibboleth EPPN = ILLiad Users.Username)
  • Specify if the validated passed value should be accepted or a default value should be used
  • Specify what to do in the case of a failed webvalidation entry such as overwrite with a default value or leave blank
  • Specify what NVTGC the user should be assigned (this function will alleviate the problem of base user accounts being assigned a default NVTGC of ILL sometimes disappearing from client views)
  • Specify if the changed field should be logged
  • Specify if the passed field should update/overwrite existing information

External Links

Questions?

If this article didn’t resolve your issue, please take a moment and answer a few questions to help improve our documentation:

Feedback