LDAP Authentication: Authentication Process

If your institution has an LDAP server available with potential ILLiad users in it, you can use that server to authenticate any customers. This server does not necessarily need to contain all potential ILLiad users, as those who do not exist can be added through the client by staff or register themselves if given a link to First Time Users.

The advantage to using LDAP is that the username and password a user enters are the same as other systems at your institution and if a user changes his/her password with the LDAP directory, that password is automatically used for ILLiad authentication as well. The disadvantage is that if your server loses connectivity to your LDAP server, those users cannot login to ILLiad because they cannot be authenticated by that external system.

For the User

• A first time user would get to the ILLiad logon screen and put in their LDAP UID for the ILLiad username and LDAP Password in place of the ILLiad password.
• ILLiad checks the LDAP server, using the supplied information. If it can successfully bind using the userid and password, then it goes to the next step. If not, it immediately returns a message to the user stating "Bad Username or Password".
• When the username and password are good, next ILLiad looks in its local Users table to see if they have registered before. If yes, then they are automatically routed to the Main Menu. If not, then they are taken to the New User Registration page where they can fill out the registration information. All of their information is stored in the ILLiad Users table. The LDAP server is used for authentication purposes only.

For the Staff

• Since the LDAP server is used for authentication purposes, the ILL staff do not need to review any customers as they register. LDAP authentication does NOT automatically clear customers within the ILLiad database. LDAP instead completely restricts access to the ILLiad system for registration and system use, so for all practical purposes, any user who successfully authenticates and gets into the system is considered to be a legitimate user. Because LDAP authentication is completely external to ILLiad, LDAP-authenticated users will still appear in the ILLiad client as not having been cleared. Customers still go through the usual Customer Clearance screens so that you have the opportunity to verify contact information and so forth. If your institution elects not to clear customers within ILLiad, users will still show in the client as not cleared, but this will not at all hinder the processing of ILL requests. Users who validate against the LDAP server can be cleared automatically by setting the AutoClearPreregisteredUsers customization key to Yes in the ILLiad Customization Manager.

Example Scenario of Using LDAP and ILLiad Authentication Together

If John Smith exists in the LDAP server with a username of jsmith7 and a password of "myunivrocks" but has never used ILLiad before, he can enter his LDAP username and password on the logon form for ILLiad. ILLiad will check to see if he exists in the ILLiad Users table under jsmith7. If not, it checks to see if he exists in the LDAP directory with that username and password. If the LDAP bind is successful, ILLiad creates a username called jsmith7 (with a blank password since it's not saved) and directs John Smith to the NewAuthRegistration.html or ChangeUserInformation.html page (if NewAuthRegistration doesn't exist) for Smith to fill out the rest of his information. ILLiad only grabs the username from LDAP and no other user data. The next time John Smith attempts to login to ILLiad, the system will check his AuthType in the Users table. If his AuthType is LDAP (which gets set when he first registers against the LDAP database), it will check the LDAP directory again to verify the username and password Smith typed into the logon form.

If Fred Funk would like to use ILLiad but is not in the LDAP directory, he can register himself from the First Time Users link or can be added to the system by staff via the client. His username can be whatever he would like, but should not conflict with a username that might be in the LDAP directory. If his username is funk and his password is "illiadrocks", then he can login on the same logon form as LDAP users. Because he manually registered or was created through the client, his AuthType is ILLiad and the web DLL knows not to try to authenticate him against the LDAP server.

For LDAP authentication, users who validate against the LDAP server 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 LDAP authentication, the WebAuthType key in the Customization Manager should be set to LDAP. Because ILLiad does not store or sync the LDAP password, you would not enable the password reset feature for LDAP customers.