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.
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 required only for deployments that use the SSO Agent. To configure the protected domain name, see Configure Company Information and Certificates.
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.
| 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.
​| 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.
​ | 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.
​| 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.
​| 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.
