Authentication Enhancements

Print Friendly and PDF Follow

As of ILLiad 9.1, authentication enhancements have been added that allow ILLiad to map user attribute fields from external authentication systems into the ILLaid User table fields. Staff is able to select which fields can be passed through to update the user record. At each login, ILLiad will validate credentials, verify access, and update any relevant identity data without having to prompt the patron to re-key information for ILLiadExclusive and RemoteAuth.  This feature can be leveraged through the use of the Automatic User Creation to automatically create and pre-clear users based on the attribute fields populated with the authentication enhancements feature. 
 

Configuring the RemoteAuthValidation Table

The RemoteAuthValidation table allows data to be mapped from an external source through RemoteAuth or ILLiad Exclusive to an ILLiad user record. This table works similarly to the OpenURLMapping table and is also utilized for web users. If there is any required information for registration that is not seeded in the RemoteAuth headers, then the user will be navigated to finish filling out the new user registration form. 
 
The RemoteAuthValidation table can be modified in the Customization Manager under Web Interface | Authentication.
 
Name Type Notes
ID int PK
NVTGC nvarchar(20) Site for this field mapping
ILLiadFieldName nvarchar(40) Name of the field in the Users table to map to
RemoteFieldName nvarchar(40) Name of the field in the remoteauth header to map from
Validation nvarchar(200) Regex for validating the remoteauth value
ValidAction nvarchar(50) Action to take when field passes validation (e.g., substitute) 
InvalidAction nvarchar(50) Action to take when the field does not pass validation (e.g., substitute) 
ValidDefault narchar(200) Substitute value to use if validation passes
InvalidDefault narchar(200) Substitute value to use if validation fails
Overwrite string If "Yes", replace ILLiad value with remoteauth value. If "IfBlank" or "No", only set changes if the ILLiad field value is blank. If not, don't save changes to ILLiad.Users.
LogIfChanged bit If true, write a logline if this field is changed. By default, the checkbox is left NULL in the client. 
 

Protected Fields

The following User fields are protected when applying updates to the user record. Updated values may be looked at and can be used with an action of "reject"; however, updated values with an action of accept/substitute would not be made to the user record. Username and NVTGC values with an action of accept/substitute would only add to the user record when a new user is created. 
 
  • Username
  • NVTGC
  • LastChangedDate
  • Password
  • PasswordHint
  • PasswordChangedDate
  • Cleared
  • AuthType
  • ExpirationDate
 

ValidAction & InvalidAction

The following are the actions that can be used for the "ValidAction" and "InvalidAction" field entries in the RemoteAuthValidation table: 
 
Actions  Values
accept Uses the value of the remoteauth field
substitute Use the default value set in ILLiad 
reject Do not accept user (this will not write to the user record and it will not allow the user to login to ILLiad)
ignore Do nothing for this field

The ValidDefault and InvalidDefault responses are determined by the actions selected for the ValidAction and InvalidAction.

RemoteFieldName

In ILLiad 9.1, the RemoteAuthUserVariable Customization Key was removed. The value of this key is now seeded to the new RemoteAuthValidations table as part of the update process for each NVTGC who has enabled RemoteAuthSupport. When using ILLiadExclusive, the RemoteFieldName should be the same name of the ILLiad User FieldName in the UserValidation table. For ILLiadFieldNames of StatusGroup, please trim the expression down to Status only. The default will use the following values:

  • ILLiad FieldName = Username
  • Validation= .+
  • ValidAction= accept
  • InvalidAction= reject
  • Overwrite= no
  • LogIfChanged= false/unchecked
Tip: Use illiad.dll?getbuildinfo to confirm which HTTP Headers are being sent to ILLiad for determining the RemoteAuthFieldNames. For more information on setting up RemoteAuth New, see RemoteAuthFieldName and HTTP Headers
 

Example Setup

ID NVTGC ILLiadFieldName RemoteFieldName Validation ValidAction InvalidAction ValidDefault InvalidDefault Overwrite LogIfChanged
1 ILL NVTGC ShibIdentityProvider *urn:mace:incommon:institution.edu* substitute reject yourNVTGC   Yes No
2 ILL Username eppn .+ accept reject     No Yes
3 ILL Lastname sn .+ accept reject     Yes Yes
4 ILL Firstname givenName .+ accept reject     Yes Yes
5 ILL SSN barcode .+ accept substitute    123123123 Yes Yes
6 ILL EMailAddress mail .+ accept reject     Yes Yes
7 ILL Department ucDepartment .+ accept substitute    Unspecified Yes Yes
8 ILL Cleared entitlement *urn:mace:dir:entitlement:common-lib-terms* substitute substitute Yes No Yes Yes
9 ILL Status affiliation *staff@institution.edu* substitute ignore Staff   Yes No
10 ILL Status affiliation *graduate@institution.edu* substitute ignore Graduate   Yes No
11 ILL Status affiliation *undergraduate@institution.edu* substitute ignore Undergrad   Yes No
12 ILL Status affiliation ^faculty@institution.edu$ substitute ignore Faculty   Yes No
 

When is RemoteAuthValidation Considered

AuthType of RemoteAuth:

When using RemoteAuth, ILLiad will always try to determine the username by evaluating the "Username" There is no "login" process when using RemoteAuth so updates that are found when evaluating the RemoteAuthValidation table will be applied if the user's LastChangedDate and the WebSessionMinutes added together are less than the current Date/Time.

The ILLiadFieldName entry will utilize the current NVTGC. If your site has a shared server setup and the current NVTGC is ILL, the alternate NVTGC will be determined from the RemoteAuthValidations mappings (ILLiadFieldName of NVTGC). Once the alternative NVTGC is determined, that NVTGC will be loaded to then check for Username. 

AuthType of ILLiadExclusive: 

RemoteAuthValidation is only used for applying updates to existing users. If sites want to preserve current functionality where data is only imported when the record is created the first time, the site would not add any entries to the RemoteAuthValidation table. The data will be applied when a user successfully logs in. Data is not imported if the user entered an invalid username/password, was disavowed, blocked, or locked out of their account. 

Questions?

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

Feedback