Chat now with support

Get Live Help
Complete Registration

Sign In

Request Pricing

Contact Sales

NOTICE! We are upgrading our support telephone services, implementing Genesys, starting the week of May 19, 2025

Cloud Access Manager 8.1.1 - Security and Best Practice Guide

Table of Contents

Optimizing Cloud Access Manager for a production environment

Memory 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

Inter-service communication

Shared secret

The Dell™ One Identity Cloud Access Manager shared secret is used to send information securely between Cloud Access Manager hosts, so that it can be stored securely in the Cloud Access Manager configuration database. In addition you will need to use the same shared secret to add new nodes to your Cloud Access Manager deployment.


	IMPORTANT: We recommend that you keep a hardcopy of the shared secret in a secure place, accessible only to staff with the authority to configure Cloud Access Manager as there is no facility to change the shared secret within the software.

Proxy mapping and URL rewriting

In order to relay web content between a web application and a browser, the proxy must:

•

Convert inbound public URLs from the browser to internal URLs which resolve to the target application on the private network.

•

Convert hypertext links in outbound web content received from the internal web application to public URLs accessible by the browser.

To rewrite the URLs correctly, the proxy maintains an internal mapping table. An application URL can be mapped to its public URL equivalent in one of two ways:

•

Folder-to-root mapping

•

Root-to-root mapping

Folder-to-root mapping

With a folder-to-root mapping the public URL includes a path component, for example:

Table 1.
Public URL	Private URL
https://www.acme.com/erp	https://erp.acme.prod.local

Folder-to-root mappings allow you to multiplex several applications with a single external hostname, for example:

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

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

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating

© 2025 One Identity LLC. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center