Ares Product Specific Considerations for Self-hosted Remote Authentication Implementation

Print Friendly and PDF Follow

Product Ares
Version 4.7 or higher
KB Permissions Public
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:

RemoteAuth authentication is slightly different than other authentication methods in that there is no default product logon page used for customers to enter a username and password. Instead, customers are redirected to the site’s authentication server (IdP for example), which retrieves the username value. If the username has been set, it checks to see if the session is still active. If it’s active, they will be taken to the Ares web pages. If the username value has not been set, the customer is taken to the authentication server’s logon page and prompted for credentials before proceeding to Ares. 

Ares installations have successfully authenticated users via SAML based Single Sign-on (SSO), PubCookie, CoSign, and Shibboleth, using this type of authentication.  Shibboleth, which uses SAML, being the most popular.

Currently, Ares 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 Ares, you must create a means to protect the Ares web folder and send an authenticated username, usually with an ISAPI filter or module. If you are using Shibboleth, for example, you would install and configure the Shibboleth Service Provider (SP) software on the Ares web server. For the username value, remoteAuth authentication expects a server variable (EPPN or uid for example) that is returned from the authenticating system and passed to Ares via the HTTP header. Because the development and support of 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 install, configure, or diagnose issues related to the authenticating system.

It is helpful to include your local SSO administrator, your Ares server administrator, Ares processing staff, and your Atlas Systems support representative in a project planning kickoff meeting.  It is also recommended to keep your local IT Security informed of your authentication goals and progress.

Ares specific settings

IIS Components (Web Directories | Protected Directory | Unprotected Directory)

Web Directories

  • Two web directories, an unprotected and protected, usually located under the Default Web Site in IIS
    • Typical Ares setup won’t have Ares default authenticated users, so you won’t need a landing page to give patrons the choice of Ares or remoteauth authentication.
  • To create the protected directory, replicate the Ares default web pages to a new folder, rename to “remoteauth” for example, copying all contents and permissions

Unprotected Directory – default Ares web pages

  • Required for a Course Management System (CMS) and Staff Proxy access from the Ares Client
    • Default Document –product logon HTML page

Protected Directory – a copy of Ares web pages

  • Provides a direct link to Ares web interface, routes users to SSO interface
    • Protected by the remote authentication
    • Default Document - Ares.dll

Customization Keys

The following is a list of Customization Keys that will need to be updated in the Ares Customization Manager to reflect the web directory configuration created for remote authentication.

Key Name Value
AuthenticationMethod Ares (if RemoteAuthSupport set to Yes, this key will be ignored)
RemoteAuthSupport  Yes
RemoteAuthUserVariable Unique identifier released by the authentication system
RemoteAuthWebLogoutURL Site supplied URL to direct the patron to after logout
RemoteAuthWebPath Local path to the protected directory
StaffProxyWebURL   URL for the unprotected directory
SystemURL      URL for the protected directory
WebServiceURL   URL for the web service in the unprotected directory

Additional Information

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.
  • Ares access exclusively through a CMS does not require remote authentication configuration
  • Ares access through a CMS and directly to the Ares web interface does require remote authentication configuration
  • When allowing dual access, the unique identifier used by the CMS must match the unique identifier being passed by the remote authentication system
    • Is there a matching field that you can get via your LTI parameters from your CMS?
    • If a username conversion is needed in order to make existing Ares users have the username that matches the RemoteAuthUserVariable, Atlas staff can perform a username conversion. An estimated fee for this service is $1500.
  • When allowing dual access and utilizing Course and User loads, the unique identifier used by the CMS must match across all three entities
  • Go tohttps://yourservername/ares/ares.dll?getbuildinfo to help confirm the name of remoteauth attributes actually being released and username
  • RARE: If allowing users to login to Ares without authentication via CMS or SSO, a dual auth portal would need to be installed, configured, and customized. A quote is issued only if Atlas web design services are needed.
  • A test server is very helpful during the implementation of SSO. If you need a quote for Atlas to install and support a local test server, please let us know.     

Sample Responsibility Matrix:




Schedule project kickoff meeting

Local staff

Include SSO administrator, your Ares server administrator, Ares processing staff, IT Security staff (optional), and your Atlas Systems support representative

Create & install Certificates if needed

Local staff


Notify end users of changes and potential downtimes for implementation and testing

Local Staff

A test server can minimize this impact

Install and configure Shibboleth on local Ares server

Local staff


Update Ares Customization Keys

Local staff with Atlas Support if needed


Customize web pages to indicate new login credentials required (if needed)

Local staff with Atlas Support if needed


Test & Troubleshoot

Local staff with Atlas Support if needed




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

Contact Support