You can create a vanity URL for your site. When doing so, please be aware of the following:
Prerequisites
Before configuring your custom domain, please ensure you meet the following requirements:
- Ability to create a CNAME record with your domain's DNS provider (e.g., GoDaddy, AWS Route 53, Cloudflare).
- Your custom domain must be a subdomain that is part of your existing DNS zone and not a separate delegated zone with its own NS or SOA records.
- Example of valid:
access.mycompany.com (where mycompany.com is managed in the same DNS zone).
- Example of invalid:
access.mycompany.com
code> if it has its own NS/SOA records (making it an independent zone).
- As with root domains, you cannot place a CNAME at the apex of any DNS zone (e.g.,
mycompany.com or the root of a delegated subdomain).
Complete the Following Steps:
For the following examples, assume that a firm named Sample Enterprises Inc is implementing IdentityNow on their own domain "Sample.com".
-
Decide on the appropriate URLs for hosting IdentityNow on your own domain:
NOTE: All URLs must be unique. For deployments that use multiple sites such as a production and sandbox site, append a postfix like "sandbox" or "sb" to the domain for the Sandbox site to meet this requirement.
-
Obtain the necessary TLS certificates and keys. We support the following options for obtaining TLS certificates. Only one of the options may be used for a specific site:
-
TLS Certificate Provisioning. Have platform use a fully automated process to provide and manage the TLS certificate for your custom domain through Cloudflare. This is the standard preferred method and requires no action from you.
Advantages:
The certificate is provided free of charge.
Certificate issuance and renewal are handled automatically by Cloudflare.
Security Model:
To ensure maximum security, the certificate's private key is managed directly by Cloudflare and is never exposed.
-
Generate everything on your own and send the signed certificate, certificate key, and intermediate certificate to SailPoint
Advantages:
- The certificate request process is completely under your control
Potential drawbacks:
- The certificate's private key has to be transmitted to us using some secure transfer method. This greatly raises the exposure of your private key. You need to decide if this risk is acceptable.
- You will be responsible for handling certificate renewal.
-
Send your hosted zone names and SSL/TLS certificate(s) to SailPoint. Refer to How do I generate a TLS certificate and key for my vanity URL? for details.
-
NOTE: Your virtual appliances must be able to resolve both records (sites) with the same NS information. As a result, you might also need to create records on your internal DNS servers. This might be true if:
- You use separate DNS servers for employees and servers
- You have a split-horizon DNS configuration
- You otherwise don't manage your external DNS
-
After these steps have been completed, SailPoint provisions your site. Once complete, you and your SailPoint engagement team may start setting up the site for your use cases.
Frequently Asked Questions
Refer to the following frequently asked questions for more information about the process:
NOTE: For cert-specific questions, see How do I generate a TLS certificate and key for my vanity URL?
-
Do I need a separate certificate and domain for SSO functionality?
We no longer use a separate hostname for the SSO component. This means that for each deployment, only a single DNS zone with a single certificate needs to be generated.
-
Can we use static IP addresses?
We're unable to use static IPs due to limitations in AWS. Their load balancing service uses DNS, but they rotate the machines so we're unable to identify a single address to use.
-
What is an example of a supported format for the URLs?
The Sample company might request the following URLs:
-
Why is subdomain delegation necessary (Can we use CNAMEs instead)?
Due to a problem in Microsoft's IWA (Kerberos) implementation in certain products, domains has to resolve to an A record in order for them to authenticate successfully (as described here). To ensure operability of all products IdentityNow currently support, we only support domain delegation as described above.
-
Why do the DNS entries have to be public?
The DNS entries have to be public because SailPoint staff, external employees, and any external integrations you build also needs to be able to communicate with your IdentityNow site.
