Understanding proxy URL mappings
The proxy URL mapping defines how Cloud Access Manager will proxy the web application. Typically the entire web server serving the application will be included by the proxy using a dedicated Domain Name System (DNS) alias assigned to the proxy. This is the preferred mapping method and is compatible with the most applications. Internally we refer to this type of mapping as a root-to-root mapping.
A root-to-root mapping requires a dedicated DNS alias for the application. The DNS alias typically contains the name of the application, for example owa.webapps.democorp.com. This new fully qualified domain name (FQDN) must be within the wildcard DNS subdomain created during the Cloud Access Manager installation and which will resolve to the public IP address used by the proxy. For example, if you created the wildcard DNS subdomain *.webapps.democorp.com during installation, you could now use an FQDN of owa.webapps.democorp.com to proxy an Outlook Web Access application or sp2010.webapps.democorp.com to proxy a Microsoft SharePoint Server 2010 application. For further information on creating a wildcard subdomain, please refer to the One Identity Cloud Access Manager Installation Guide and the One Identity Cloud Access Manager Configuration Guide.
If you did not create a wildcard DNS subdomain for Cloud Access Manager during installation, you will need to manually add the new FQDN into your public DNS. The new FQDN must be covered by the wildcard Secure Sockets Layer (SSL) certificate you are using to avoid certificate errors being reported by the client browsers.
When you configure this type of mapping, leave the path box empty. If you enter a path value, the mapping type will change from root-to-root to a symmetric mapping.
Alternatively, some applications are installed entirely within their own virtual directory on the web server where they reside. One example of such an application is One Identity Active Roles Server, which installs into the virtual directory/ARServerAdmin. Here it is possible to map the application path onto the same path on the proxy’s public hostname allowing that hostname to be used instead of requiring a new public DNS Alias to be created, for example www.webapps.democorp.com/ARServerAdmin. Internally we refer to this type of mapping as a symmetric mapping.
You can map multiple paths for an application, but you can only map paths that are unique to the application and not common path names, which could clash with other applications. For example, if you map the path /common for one application you cannot map the same /common path to another unrelated application, as you cannot map them both onto the same path on the proxy’s public hostname.
Often applications will not be installed within a self-contained virtual directory making symmetric mapping an unsuitable method for mapping them, for example OWA or SharePoint 2010. Attempting a symmetric mapping here can result in images not appearing on the application’s pages, missing functionality, broken links and other unexpected behavior. Identifying whether an application is suitable for symmetric mapping can be difficult and so, if possible, it is more reliable to use a root-to-root mapping instead.
Using the network view on the browser’s developer tools, or a tool such as Fiddler, will help determine if all of the requests to the application reside within a single virtual directory. For example, in the image below you can see that all requests reside within the /mantis virtual directory making this application suitable for a symmetric mapping:
The symmetric mapping type is activated whenever you enter a path on the Proxy URL page.
When you configure a mapping, it is important to map to a directory or folder. It is not possible to map to an individual file.Cloud Access Manager must map to a whole web application, not a single page or file within an application. You cannot, for example, only proxy the login page by entering qpm/login.aspx into the path field.
LFIT-Login Form Inspection Tool
LFIT is a tool provided within Cloud Access Manager to enable fast identification of the values necessary to form fill against a supplied form. Generally LFIT collects the necessary data without issue, but occasionally it may fail to find certain fields or values. This is an indication that there is something non-standard about the login form or that JavaScript functions may be in place. Sometimes you can simply click in the fields manually to populate the values, at other times you may need to enter the values on the Form Fill Details page of the application wizard.
|
|
NOTE: If you are using LFIT in Internet Explorer, your Cloud Access Manager website will need to be in the Local intranet zone. For information on how to add the Cloud Access Manager proxy hostname to the intranet zone in Internet Explorer, please refer to the Form Fill Authentication section in the One Identity Cloud Access Manager Configuration Guide. |
