You can create a vanity URL for your site. When doing so, please be aware of the following:
- Refer to Frequently Asked Questions for details about our process.
- For general information about DNS entries and other information described in this document, see IETF RFC-1035 and Wikipedia - NS Records.
Prerequisites:
- Ability to create NS records for subdomains in your domain: Certain DNS providers do not allow NS records to be created for a subdomain (we currently know Network Solutions has this issue). Please check with your registrar/DNS provider to make sure you are able to create NS records for subdomains before proceeding. It is important to have this figured out before selecting a vanity domain name for your service.
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".
1. Decide on the appropriate URLs for hosting IdentityNow on your own domain:
- Example: Production Site - https://iam.sample.com; Sandbox/Staging Site - https://iam-sb.sample.com
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.
2. 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:
- Have SailPoint request and host the certificate for your vanity domain through AWS's Amazon Certificate Authority. This certificate will be provided to you free of charge. This is the preferred method.
- Advantages:
- The certificates are provided free of charge to you from AWS's Amazon Certificate Authority.
- Certificate renewal will be handled by us. You will still be required to approve the renewal, so you will still have control.
- Approval can be done by a verification email sent to the domain administrator on record with your domain registrar. An arbitrary email address cannot be used.
- This is the most secure option. It minimizes the possibility of your private key being compromised. Even we won't have access to the key itself. It is stored in AWS's secure key storage.
- This method offers the least complication and requires you to select an approval link in an email at its simplest.
- Potential drawbacks:
- Neither you nor us will have access to the private keys.
- You may need to approve the certificates twice due to how AWS handles certificates and regions.
- Advantages:
- Have SailPoint generate the certificate signing request (CSR). You then fulfill the request, and return the signed certificate and CA bundle to SailPoint
- Advantages:
- You can use your organization's preferred certificate authority for the certificate
- We will have possession of the private key to the certificate, you don't have to figure out how to securely transmit it to us
- Potential drawbacks:
- Your organization may require you to have possession of your certificate's private key
- You will be responsible for handling certificate renewal
- Our engineers will have access to your private key
- Advantages:
- 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.
- Advantages:
3. Send your hosted zone names and SSL/TLS certificate(s) to SailPoint. Refer How do I generate a TLS certificate and key for my vanity URL? for details.
4. SailPoint sends you the NS records you need to set up in both internal (if applicable) and public DNS.
5. You create NS records for each site on your DNS registrar. This requires creating a subdomain delegation (also know as 'NS' record) entry inside your zone, with the value being the nameservers we provided in step 4. This needs to be done for all IdentityNow sites that are part of your engagement. To see the proper delegation of your subdomain entries to the Amazon authoritative nameservers, see the FAQs.
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
6. 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?
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.
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.
The Sample company might request the following URLs:
- iam.sample.com
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.
Although we refer to DNS records in this document, when it comes to delegation, you will technically delegate an entire subdomain for each site. Going with our Sample Enterprise example, they will need to delegate the subdomain 'iam.sample.com' to the Nameservers we provide. Note that they do not have to delegate 'sample.com'. In this subdomain, we will create the record 'iam.sample.com' to point to the correct resources that serve your IdentityNow site. The record is indeed the same as the subdomain.
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.
In step 5, it says I must create NS records for each site on your DNS registrar, which requires creating a subdomain entry inside your zone. The values are the Nameservers we provided in step 4.
The screenshot below demonstrates the proper delegation of your subdomain entries to the Amazon authoritative nameservers. Once the request reaches these nameservers, the correct record will be returned.
