Some institutions would like to limit access to the ILLiad web to a known list of users. This list can come from any external database and be imported into the UserValidation table in ILLiad for the ILLiad web to verify against before allowing users to register or login.
The UserValidation table is accessible from the Customization Manager under Web Interface | Authentication. This allows staff to make any minor corrections to the table or add an individual user. All users must be in the UserValidation table. Users cannot self-register from the web, and staff cannot add users through the client. For adding large numbers of users to the UserValidation table, though, staff should use an automated script to import an exported list into the UserValidation table on a database level.
When John Smith first attempts to use ILLiad, he would type in his library card number and his lastname into the username and password fields on the logon form. He would not need to click on a First Time Users link to register. ILLiad checks to see if the username 123456789 exists in the UserValidation table. If that username is found, ILLiad then checks whether the encrypted value of "smith" matches the value in the Password field of UserValidation. It doesn't match (because the Password field is blank), so ILLiad then checks if the value of "smith" matches the value in the PlainTextPassword field of UserValidation. That value matches so John Smith's username is added to the Users table with an encrypted version of "smith" stored in the Password field of the Users table. John Smith is then directed to the NewAuthRegistration.html or ChangeUserInformation.html page (if NewAuthRegistration does not exist) to fill out any other necessary information for his user account. If other fields were populated in the UserValidation table, those values would appear on the registration form.
After registering, if John Smith returns to the ILLiad web, he would again enter his username of 123456789 and his password of "smith" on the logon form. ILLiad would verify that 123456789 exists in Users as well as verify that 123456789 still exists in UserValidation. It would no longer verify the Password or PlainTextPassword fields in UserValidation, but would verify the encrypted value of what John Smith typed in with the encrypted value stored in the Users table. As long as John Smith has not been disavowed by staff in the client, he is then allowed to login to the system.
For ILLiad Exclusive authentication, users who exist in the UserValidation table can be cleared automatically by setting the AutoClearPreregisteredUsers customization key to Yes in the Customization Manager. If that key is set to Yes, those pre-cleared users can be sent a welcome email by turning on the AutoClearSendEMail key to Yes in the Customization Manager. The template for that email can be accessed from the Customization Manager. As of ILLiad 8.6, all email templates are stored in the database and can be accessed and edited from the ILLiad Customization Manager. Default email template names should not be changed. Changing default email template names will result in failed emails.
For ILLiad Exclusive authentication, the WebAuthType key in the Customization Manager should be set to ILLiadExclusive. Customers could technically reset their passwords after registering with the system, but it may not follow with your model of known usernames and passwords (i.e. library card and last name). However, users will be required to change their passwords after ILLiad has been updated to version 9.0. For more information on the ILLiad 9.0 update, see ILLiad 9.0 Release Notes.