If your institution has an LDAP server available with potential Aeon users in it, you can use that server to authenticate any customers. This server does not necessarily need to contain all potential Aeon users, as those who do not exist can be added through the staff client by staff or register themselves if given a link to the First Time Users web page.
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 Aeon authentication as well. The disadvantage is that if your server loses connectivity to your LDAP server, those users cannot login to Aeon because they cannot be authenticated by that external system.
LDAP passwords are not stored in the Aeon database and are only used when typed in by the user to match against the LDAP server during registration and login. The password field in the Aeon database will store the encrypted version of a blank value but is not used for any authentication.
LDAP Setup
For LDAP authentication, the WebAuthType key in the Aeon Customization Manager should be set to LDAP. Because Aeon does not store or sync the LDAP password, you would not enable the password reset feature for LDAP customers.
Customizing your LDAP Settings
Setting up LDAP authentication requires a few customization keys to be updated in your Customization Manager. All keys are located at Web Interface | LDAP except for WebAuthType, which is located at Web Interface | Authentication.
| LDAPBindStyle | OneStep performs one or more binds to find the user while TwoStep does an initial bind to allow Aeon to search the directory and then searches for that user. |
|---|---|
| LDAPInitialBindDN | Used only for TwoStep LDAP where this is the initial bind that authenticates Aeon to search for the user attempting to register or login. |
| LDAPInitialBindPassword | Used only for TwoStep LDAP and is the password for the LDAPInitialBindDN. |
| LDAPPortNo | The port used for connecting to the LDAP server (389 by default). |
| LDAPSearchFilter | Used only for TwoStep LDAP where the initial authentication is a bind and Aeon then performs a search for the potential Aeon user. Determines the user's DN from the UserID given on the login form. |
| LDAPSearchPrefix | Used only for OneStep LDAP and is the prefix to the bind used to find the potential Aeon user. |
| LDAPSearchScope | Used only for TwoStep LDAP and should rarely need to be changed from SubTree. |
| LDAPSearchSuffix | Used for both OneStep and TwoStep LDAP but in slightly different ways. See details below. |
| LDAPSecureSSL | If set to Yes, Aeon uses the LDAPSecureSSLPort and not the LDAPPortNo value. |
| LDAPSecureSSLPort | Only used if LDAPSecureSSL is set to Yes. The default value for most LDAP servers is 636. |
| LDAPServerName | The name of the LDAP server. |
| LDAPVersion | Tells Aeon which version of LDAP to connect to. Most servers use version 2 or 3. |
| WebAuthType | Tells Aeon to use LDAP authentication. |
Binding
LDAPSearchSuffix is used by both OneStep and TwoStep LDAP but in slightly different ways.
One Step
For OneStep LDAP the suffix is either a single suffix or pipe-separated list of different suffixes for Aeon to attempt to use for a bind. The entire bind would involve the values from: LDAPSearchPrefix + <username entered> + , + LDAPSearchSuffix. If that bind fails, Aeon will attempt the same combination but with the second LDAPSearchSuffix in the customization key.
Two Step
For TwoStep LDAP, Aeon uses the LDAPSearchFilter to search in the LDAPSearchSuffix and any subtrees under that location in the LDAP directory. Most sites using TwoStep set this value fairly high in the directory to allow for searching in multiple subtrees for a match, but that may vary based on who is allowed to use Aeon.
Example Scenario of using LDAP and Aeon authentication together
If John Smith exists in the LDAP server with a username of jsmith7 and a password of "myunivrocks" but has never used Aeon before, he can enter his LDAP username and password on the login form for Aeon. Aeon will check to see if he exists in the Aeon 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, Aeon creates a username called jsmith7 (with a blank password since it's not saved) and directs John Smith to the NewAuthRegistration.html registration page for Smith to fill out the rest of his information. Aeon only grabs the username from LDAP and no other user data. The next time John Smith attempts to login to Aeon, 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 login form.
If Fred Funk would like to use Aeon 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 staff client. His username can be whatever he would like, but it should not conflict with a username that might be in the LDAP directory. If his username is ffunk and his password is "Aeonrocks", then he can log in on the same login form as LDAP users. Because he manually registered or was created through the staff client, his AuthType is Aeon and the web DLL knows not to try to authenticate him against the LDAP server.