Protected Domain Name

Document created by RSA Information Design and Development on Aug 18, 2017Last modified by RSA Information Design and Development on Nov 16, 2018
Version 17Show Document
  • View in full screen mode

A protected domain name is a unique domain name for your deployment. You determine this name as part of completing the "Plan" section in your Quick Setup Guide.

Note:  The protected domain name is not required for deployments that do not use the SSO Agent.

A protected domain name is a subdomain prepended to your registered domain name. A protected domain name is used by all traffic managed by the identity router, for both messages to and from users and messages to and from protected applications. Users see the hostnames within the protected domain name in the browser address bar when accessing protected applications.

 

Impacted Network Components

The following major network components are impacted by a protected domain name:

 
  • Company Domain Name System (DNS) server entries.
  • Identity router SSL certificate.
  • All single sign-on (SSO) traffic to the identity router, which is encrypted by a single wildcard Secure Sockets Layer (SSL) certificate for the protected domain name.
 

Guidance for Selecting a Protected Domain Name

After you deploy the SSO Agent, it is difficult to change the protected domain name, so select the name carefully. For example, changing the protected domain name requires users to update bookmarks and administrators to update links from other systems, including SAML-enabled application configurations. You must update all HFED applications with the new protected domain name.

The following sections provide both good and bad examples of protected domain names. Review these sections for guidance.

 

Protected Domain Name - Correct Usage Example

If you create two environments (for example, test and production), each environment must have a unique protected domain name to isolate the environments, as shown in the following table.
Protected Domain Name Sample Identity Router Portal Hostname
Test environment test.example.com portal.test.example.com
Production environment sso.example.com portal.sso.example.com
 

Protected Domain Name - Incorrect Usage - Example 1

Multiple environments may not use the same protected domain name. The protected domain names in the following table have unique hostnames but do not have a unique subdomain within example.com.

Do not follow these examples.
Protected Domain Name Sample Identity Router Portal Hostname
Test environment sso.example.com test.sso.example.com
Production environment sso.example.com portal.sso.example.com
 

Protected Domain Name - Incorrect Usage - Example 2

In multiple environments, all protected domain names must be at the same level without nesting. In the following example, the protected domain name for the test environment is incorrectly nested within the protected domain name for the production environment. If two protected domain names are nested and a user accesses applications from both environments with the same browser, the identity router traffic might get stuck in a loop. The user must clear browser cookies in order to sign into the application portal or protected applications.

Do not follow these examples.

                    
Protected Domain Name Sample Identity Router Portal Hostname
Test environment test.example.com portal.test.example.com
Production environment example.com portal.example.com

 

 

Protected Domain Name - Incorrect Usage - Example 3

The examples shown in the following table can work, but are not recommended. These examples use an extra subdomain, increasing the possibility that someone might later add an environment with sso.example.com as the protected domain name, which would introduce nesting.

Do not follow these examples.
Protected Domain Name Sample Identity Router Portal Hostname
Test environment test.sso.example.com portal.test.sso.example.com
Production environment prod.sso.example.com portal.prod.sso.example.com
 

Protected Domain Name - Incorrect Usage - Example 4

Avoid using registered domains as the protected domain name (for example, example.com). Doing so can make it difficult to obtain wildcard DNS entries or SSL certificates.

Do not follow these examples.
Protected Domain Name Sample Identity Router Portal Hostname
Test environment example.local portal.example.local
Production environment example.com portal.example.com

Wildcard CNAMES are helpful for adding protected applications over time. Typically, these names can be configured for the identity router only with a protected domain name that includes a subdomain.

 

 

You are here
Table of Contents > Company Settings > Protected Domain Name

Attachments

    Outcomes