If you do not want your users to enter a username and/or password to use Aeon, but want to pass a known username to Aeon for registration and login, you can setup RemoteAuth authentication. While there are few Aeon customizations to enable this authentication, it does require technical knowledge of setting up your external authenticating system and having that server send information to the Aeon web server.
RemoteAuth authentication is slightly different than other authentication methods in that there is no logon page used for customers to enter a username and password. In most installations, sites add an isapi filter to the Aeon web server that intercepts the request for the Aeon.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 Aeon via the http header.
Aeon installations have successfully authenticated users via PubCookie, CoSign and Shibboleth using this type of authentication. Currently, Aeon only checks for the username and does not look for other customer information (i.e. name, status, contact information etc.).
Note that RemoteAuth authentication is dependent on your existing external authentication system. In order to use RemoteAuth authentication with Aeon, you must create a means to protect the Aeon 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 Aeon, you will need to be familiar with how to create and support those yourself to use this type of authentication. While Atlas Systems can help you troubleshoot the Aeon portion of the authentication, we cannot diagnose issues related to the authenticating system.
The system is designed to use RemoteAuthentication based on the location of the actual web pages as specified by the RemoteAuthWebPath customization key. Therefore, you cannot use the testweb pages with RemoteAuth.
For RemoteAuth authentication, the WebAuthType key is not used, so can either be set to RemoteAuth as a reminder or Aeon. Because only the username is sent to Aeon and users authenticate against the remote server each time, the password reset feature does not apply for RemoteAuth authentication.
Customizing your RemoteAuth Settings
These customization keys are located in the Customization Manager under Web Interface | Authentication.
|RemoteAuthSupport||Determines if RemoteAuth is being used by one of the web directories|
|RemoteAuthUserVariable||The name of the server variable containing the Aeon username that is sent from the authenticating server.|
|RemoteAuthWebLogoutURL||The URL or local file to send a user to after logging out of an Aeon web directory controlled by remote authentication.|
|RemoteAuthWebPath||The web directory containing Aeon web files and the DLL that's controlled by remote authentication. Details on this are below.|
You can enable RemoteAuth authentication for a particular web directory while still keeping a separate web directory for users to register themselves via Standard Aeon authentication. The RemoteAuthWebPath would be the directory controlled by remote authentication while the WebPath key (Web Interface | System | WebPath) would have the directory not controlled by remote authentication. RemoteAuthSupport being set to Yes would tell Aeon to check the directory and then know if the user should be authenticated remotely or by Aeon. The WebAuthType key is not used with RemoteAuth authentication.