Chatta subito con l'assistenza

Ottieni assistenza in tempo reale
Completa la registrazione

Accedi

Richiedi prezzo

Contatta il supporto vendite

Cloud Access Manager 8.1.2 - Security and Best Practice Guide

Table of Contents

Optimizing Cloud Access Manager for a production environment

Memory Disk space HTTP connections

STS hosts Preventing direct access to applications protected by Cloud Access Manager

Fallback Shared secret Proxy mapping and URL rewriting

Folder-to-root mapping Root-to-root mapping Choosing the best mapping strategy

Rewriting relative URLs using folder-to-root Relative URLs using root-to-root

Choosing the right SSL certificate

Single host certificate Wildcard certificate Subject Alternative Name (SAN) certificate

Single sign-on methods

Security Assertion Markup Language (SAML) federation and WS-Federation HTTP Basic and NTLM Proxied form-fill Unproxied form-fill

Using a reverse proxy or load balancer with Cloud Access Manager

Inter-service communication

Root-to-root mapping

Root-to-root mappings associate a single dedicated public URL hostname with a corresponding private URL hostname, for example:

Table 3.
Public URL	Private URL
https://erp.webapps.acme.com	https://erp.acme.prod.local
https://mail.webapps.acme.com	https://owa.acme.prod.local
https:// payroll.webapps.acme.com	https://payroll.acme.secure.net

Choosing the best mapping strategy

An advantage to using folder-to-root mappings is that the Secure Sockets Layer (SSL) certificate that authenticates the public server can cover all web applications with a single hostname. Using folder-to-root mappings is less expensive than root-to-root mappings, this is because an SSL certificate that authenticates a single hostname is generally cheaper than one which protects multiple hostnames.

However, use of folder-to-root mappings is not recommended for complex web sites, particularly those which rely heavily on client-side scripting to generate dynamic content. When using the folder-to-root approach, the proxy must rewrite relative URLs embedded in the content body, and if an embedded URL is built dynamically by the application, the proxy may need special rules (filters) to rewrite it correctly.

Rewriting relative URLs using folder-to-root

Table 4.
Private URL https://erp.acme.prod.local	Public URL https://www.acme.com/erp
/images/home.jp	/erp/images/home.jpg
../scripts/login.js	../erp/scripts/login.js
reports/salesfigures2014.pdf	erp/reports/salesfigures2014.pdf
this.href.location = '/register.aspx';	this.href.location = '/erp/register.aspx';

Relative URLs using root-to-root

Table 5.
Private URL https://erp.acme.prod.local	Public URL https://erp.webapps.acme.com
/images/home.jpg	Does not need rewriting.
../scripts/login.js	Does not need rewriting.
reports/salesfigures2014.pdf	Does not need rewriting.
this.href.location = '/register.aspx';	Does not need rewriting.


	NOTE: As embedded relative URLs do not need rewriting when using the root-to-root approach there is less scope for URL rewrite problems, and the proxy can return the page to the browser more quickly. In general, we strongly recommended the root-to-root approach for both reliability and performance.

Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione

© 2025 One Identity LLC. ALL RIGHTS RESERVED. Termini di utilizzo Privacy Cookie Preference Center