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 setup RemoteAuth authentication. While there are 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 RemoteAuth authentication is dependent on your existing external authentication system. In order to use RemoteAuth authentication with ILLiad, you must create a means to protect the ILLiad web folder and send an authenticated username, usually with an ISAPI filter. Because the development and support of those ISAPI filters or other configurations for authenticating systems are 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.
- Currently, ILLiad only checks for the username and does not look for other customer information (i.e. name, status, contact information etc.).
- 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.
ILLiad installations have successfully authenticated users via PubCookie, CoSign, and Shibboleth using this type of authentication.
If your ILLiad service is hosted by OCLC and you would like to use Remote Authentication, you will need to use their middleware product, EZProxy, to connect your Authentication Service to the ILLiad server.
Remote Authentication Workflow
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.