RemoteAuth: Authentication Process & Customizing Settings

Print Friendly and PDF Follow

A bug introduced in Shibboleth v3.2.2.2 may cause variable values to be duplicated in User records created through RemoteAuth. To resolve this issue, please use the following setting in your Shibboleth RequestMapper configuration:

If you do not want your users to enter a username and/or password to use Ares, but want to pass a known username to Ares for registration and login, you can set up RemoteAuth authentication. While there are few Ares 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 Ares 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 Ares web server that intercepts the request for the Ares.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 Ares via the http header. Ares installations have successfully authenticated users via PubCookie, CoSign, and Shibboleth using this type of authentication.

Currently, Ares only checks for the username and does not look for other customer information (i.e. name, status, contact information etc.).

Shibboleth attribute IDs must be written using all uppercase letters in attribute-map.xml for the associated variable to pass through to the Ares DLL.

Note that RemoteAuth authentication is dependent on your existing external authentication system. In order to use RemoteAuth authentication with Ares, you must create a means to protect the Ares 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 Ares, 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 Ares portion of the authentication, we cannot diagnose issues related to the authenticating system.

Please note that the testweb will not function under RemoteAuth. The system is designed to use Remote Authentication based on the location of the actual web pages. Therefore, you cannot use the testweb pages with RemoteAuth.

Customizing your RemoteAuth Settings

These customization keys are located in the User Authentication and Web sections of the customization manager.


If enabled, your Ares dll will use remote authentication services. Remote authentication requires additional setup by that service (Shibboleth, CAS, CoSign, etc.). RemoteAuthSupport being set to Yes would tell Ares to check the directory and then know if the user should be authenticated remotely or by Ares. Example: Yes, No


The HTTP Server Variable that Ares can look at to identify the user. Default: HTTP_REMOTE_USER


HTML file or URL to be displayed when logging out of the Ares web interface. Example: Glogon2.html


For RemoteAuth authentication, users who validate against the RemoteAuth server can be cleared automatically by setting the AutoClearPreregisteredUsers customization key to Yes.



If this article didn’t resolve your issue, please contact Atlas Support for assistance:

Contact Support