• 印刷
• MY ダウンロード ()

• サポート
• 技術文書
• Cloud Access Manager 8.1.2
• Cloud Access Manager 8.1.2 - Security and Best Practice Guide

Cloud Access Manager 8.1.2 - Security and Best Practice Guide

コンテンツのナビゲーション  

Optimizing Cloud Access Manager for a production environment

Proxy hosts

Memory Disk space HTTP connections

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

Operations

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

Security

Inter-service communication

• Viewing Topics 13 - 16 of 28

×

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.

•  前回
• Viewing Topics 13 - 16 of 28
• 次へ 

この文書を検索 この製品バージョンに対応するすべての文書を検索 この製品に対応するすべての文書を検索 すべての文書を検索

×

 サポートへようこそ

*product*のオンラインサポートヘルプは、関連会社のサポートサイトで参照できます。「Continue（続行）」をクリックすると、*product*の適切なサポートコンテンツとアシスタンスへ移動します。

関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択

© 2025 One Identity LLC. ALL RIGHTS RESERVED. 利用規約 プライバシー Cookie Preference Center