Product | Ares |
Version | 4.7 or higher |
KB Permissions | Public |
exportDuplicateValues="false"
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
- 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:
Task |
Responsible |
Notes |
---|---|---|
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 |
|