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

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

Cloud Access Manager 8.1 - Security and Best Practice Guide

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

Optimizing Cloud Access Manager for a production environment

Proxy hosts

Memory 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

Security

Inter-service communication

• Viewing Topics 9 - 12 of 26

×

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

•  前回
• Viewing Topics 9 - 12 of 26
• 次へ 

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

×

 サポートへようこそ

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

関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択

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