exportDuplicateValues="false"If you do not want your users to create a username and/or password to use ILLiad, but want them to use an existing institutional username and password to access ILLiad for registration and login, you can set up RemoteAuth authentication. While there are a few ILLiad customizations to enable this authentication, it does require technical knowledge of setting up your external authentication system and having that server send information to the ILLiad web server.
Note that in order to use RemoteAuth authentication with ILLiad, you must either create a means to protect the ILLiad web folder and send an authenticated username (usually with an ISAPI filter) or configure the integrated SAML module provided in ILLiad v9.2 if you are unable to install your Service Provider module on the ILLiad Server. If using ISAPI filters or other configurations for authenticating systems outside of ILLiad, you will need to be familiar with how to create and support those yourself to use this type of authentication. While Atlas Systems and OCLC can help you troubleshoot the ILLiad portion of the authentication, we cannot diagnose issues related to the authenticating system.
RemoteAuth authentication is slightly different than other authentication methods in that there is no login page used for customers to enter a username and password. In most installations, sites add an ISAPI filter to the ILLiad web server that intercepts the request for the illiad.dll in the RemoteAuth folder. If the username value has not been set, it redirects the user to the authentication server. If the username has been set, it checks the authentication server to see if the session is still active. RemoteAuth authentication expects a server variable that is set to the authenticating system and passed to ILLiad via the HTTP header.
-
By default, ILLiad only checks for the username and does not look for other customer information (i.e. name, status, contact information, etc.) unless the RemoteAuthValidation table has been configured to accept additional RemoteAuth attributes.
Secure Handling for Users of Different Authentication Types
As of ILLiad v9.1, the DLL will check to ensure that the user entering the system through a remote authentication endpoint matches an existing ILLiad user in both username and authentication type (AuthType). In the case where a new RemoteAuth user's username has already been taken by a user created with the basic ILLiad authentication type (i.e., where the existing user's AuthType is 'ILLiadAuth,' or where the AuthType is 'Default' if the WebAuthType is set to 'ILLiadAuth'), the RemoteAuth user will be redirected to the Error.html page upon the initial login attempt and the SLSingleSignInUsernameInUse status line will appear. The text on the error page will direct the user to contact staff to resolve the issue. - The system is designed to use RemoteAuthentication based on the location of the actual default web pages as specified by the RemoteAuthWebPath customization key. Therefore, you cannot use the testweb pages with RemoteAuth.
Examples
ILLiad installations have successfully authenticated users via PubCookie, CoSign, and Shibboleth using this type of authentication.
Remote Authentication Workflow
Auth Portal
While each authentication method has some special features to it, there are some concepts that are common to all authentication methods in ILLiad.
- Usernames must be unique across the database.
- Passwords stored by ILLiad are one-way encrypted and cannot be revealed to staff or customers if forgotten. Some authentication methods such as LDAP and RemoteAuth do not store the user's password in the database, but those that do encrypt it so that it cannot be reversed to the plain text version and only compared to what the user enters at login.
- Regardless of the pre-registering or authenticating system, all users can be blocked and/or disavowed by staff in the Client. ILLiad checks for the user's cleared status last before attempting to display the Main Menu or a request form. The AllowBlockedAccess customization key, which allows blocked users access to their web accounts while prohibiting them from placing requests, can be used with all authenticating systems.
- Users who do not register via the ILLiad web interface can be added by staff in the ILLiad client using the New User ribbon command. This allows staff to accept exclusive authentication methods such as LDAP, PatronAPI Exclusive, ILLiad Exclusive, etc as defined by the WebAuthType or override the default value and assign a value of ILLiad by checking the ILLiad Authentication check box to select Basic ILLiad Authentication.