Authentication Enhancements: RemoteAuthValidation Table

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

A bug introduced in Shibboleth v3.2.2.2 may cause variable values to be duplicated in User records created through RemoteAuth. To resolve this issue, please use the following setting in your Shibboleth RequestMapper configuration:
exportDuplicateValues="false"

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 that has enabled RemoteAuthSupport. When using ILLiadExclusive, the RemoteFieldName should be the same name as 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
Shibboleth attribute IDs must be written using all uppercase letters in attribute-map.xml for the associated variable to pass through to the ILLiad DLL.
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
 

Passing a Static Default Field Value into the User Record

If you would like a certain field to contain a static default value for your ILLiad user records, you will have to configure an entry for that field with this default value specified in the RemoteAuthValidation table. This will set the field in the user's database record to that value, which will also pre-populate the value for that field on the NewAuthRegistration and ChangeUserInformation web pages.

For example, if you would like all user records to contain a LoanDeliveryMethod field value of "Hold for Pickup" by default, you would need to create the following entry for the LoanDeliveryMethod field in the RemoteAuthValidation table:

NVTGC ILL
ILLiadFieldName LoanDeliveryMethod
RemoteFieldName ILLiadDefault_LoanDeliveryMethod
Validation .+
ValidAction ignore
InvalidAction substitute
ValidDefault NULL
InvalidDefault Hold for Pickup
Overwrite No
LogIfChanged Yes
  • The NVTGC column should contain the relevant NVTGC value that should be set in the user record
  • The ILLiadFieldName column should contain the name of the ILLiad database field for which to set the default value
  • The InvalidDefault column should contain the default value you want to pass into that field
  • The RemoteFieldName column should be given a value that does not exist in the remote headers so that the field will always fail validation and thus populate with the static value specified in the InvalidDefault column

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 contact Atlas Support for assistance:

Contact Support