Web Server Protected
Overview
AppsAnywhere runs on the Apache web server, for which a wide range of single sign-on systems have their own module for handling authentication. The authentication module enabled on the web server should be able to pass through identity information about the user via a CGI-compliant server variable, which can then be used by AppsAnywhere to authenticate and authorize the user.
AppsAnywhere currently only supports an Apache web server when integrating with authentication modules, and provides quick set up for two options:
Windows Pass-Through
CoSign
It is worth noting that a fully configured Windows pass-through method is defined for you during installation of AppsAnywhere - you do not need to worry about having to add this one yourself!
In this article, we will go through everything you need to know to add a web server authentication module for single sign-on.
Adding Web Server Protected Methods
If you are unfamiliar with the process for adding new SSO methods, steps for doing this and information about common settings associated with all SSO methods can be found on the Single Sign-On Settings page. When selecting which method to add however, be sure to pick from the Web Server Protected Module category, and select the one that corresponds to the web server you are using.
Adding a new method in AppsAnywhere will not currently configure the web server automatically for you. If you wish to add a new one, please contact AppsAnywhere support for assistance with this.
For CoSign using Apache, select the following:
For any other module running on Apache, select:
Web Server Protected Specific Settings
Field Name | Description | Intended Value |
|---|---|---|
Server Module Name | The name of the authentication module to load as seen by the web server. Note that this is not loaded by AppsAnywhere and should be handled independently. | The name you would use to enable the module within the web server, e.g. mod_auth_kerb |
Username Server Variable | To determine the identity of the user, the username should be made available to AppsAnywhere within the server variable set by the authentication module. The name of this server variable can then be provided here so that during the authorization process AppsAnywhere can extract this information. This is the username that will be matched against the provided username format. | The CGI-compliant server variable name provided to AppsAnywhere containing the username, e.g. REMOTE_USER |
Domain Server Variable | In order for AppsAnywhere to know which local domain the authenticating user is a part of, the name of a server variable that provides this information may be required. If multiple LDAP connections have been selected, there is a single scenario where this would be the case:
| The CGI-compliant server variable name provided to AppsAnywhere containing the domain the user is part of, e.g. REMOTE_DOMAIN |
Testing
Once you have completed configuration, you can test it is functioning correctly by following the steps described in Single Sign-On Settings and those specific to the associated authentication module.
Because the steps will likely differ between modules, it is best you consult the documentation around it to determine expected outcomes after navigating to the URL in AppsAnywhere.
If you run into any issues during testing, there are a few troubleshooting steps applicable to all modules you can take based on the problem you are seeing:
If you remain in AppsAnywhere but are not logged in (ending up back at the login page):
Ensure the appropriate LDAP connections have been assigned to the SSO method
If multiple have been set and the provided username has no domain or short domain name suffix or prefix, then also ensure a server variable containing the user's domain is being set
Ensure the set Username Server Variable matches that which is being provided
If the Domain Server Variable has been set, ensure it matches that which is being provided