Tenant environments
Ping Identity provides you with three or more PingOne Advanced Identity Cloud tenant environments to let you create an IAM structure that suits your organization:
-
Development, staging, and production tenant environments let you build, test, and deploy your IAM configuration and applications. These environments share the same configuration.
-
A user acceptance testing (UAT) tenant environment[1] lets you test new features in a production-like environment using the same configuration as your development, staging, and production environments.
-
A sandbox tenant environment[2] lets you build and experiment with new features in a development-like environment using a standalone configuration. It tracks the rapid release channel, which lets you test the newest features and fixes from Ping Identity before they are deployed to your other environments.
For a full comparison, learn more in Comparison of environment characteristics.
Security architecture
Advanced Identity Cloud provides full-tenant isolation in a multi-tenant cloud service by using individual trust zones. Each tenant environment is a dedicated trust zone that shares no code, data, or identities with other customers’ environments. This prevents any accidental or malicious commingling. All data is encrypted at rest and in transmission to prevent unauthorized access and data breaches.
Each tenant environment is built from a standard template, hosted using a common technology base, maintained according to a consistent set of processes, and continually upgraded to the latest code base. The infrastructure uses consistency, standardization, and automation to deliver a highly available service.
Comparison of environment characteristics
General characteristics
| Characteristic | Sandbox[2] | Development | UAT[1] | Staging | Production |
|---|---|---|---|---|---|
Rapid |
Regular |
Regular |
Regular |
Regular |
|
Mutable static configuration |
Yes |
Yes |
No |
No |
No |
Part of a promotion pipeline |
No |
Yes |
Yes |
Yes |
Yes |
Highly available |
No |
No |
Yes |
Yes |
Yes |
Max identities supported |
10k |
10k |
Based on your subscription |
Based on your subscription |
Based on your subscription |
Penetration and load testing allowed |
No[3] |
No[3] |
Yes[3] |
Yes[3] |
No[3] |
Uptime monitored with Pingdom |
No |
Yes |
Yes |
Yes |
Yes |
Monitored with statuspage.io |
No |
No |
Yes |
Yes |
Yes |
Personally identifiable information allowed |
No |
No |
Yes |
Yes |
Yes |
Service level agreement |
No |
No |
No |
No |
Yes |
Log retention (days) |
1 |
30 |
30 |
30 |
30 |
Backup interval (hours) |
1 |
1 |
1 |
1 |
1 |
Backup retention (days) |
3 |
7 |
30 |
30 |
30 |
Recovery time objective (RTO) characteristics
| Characteristic | Sandbox[2] | Development | UAT[1] | Staging | Production |
|---|---|---|---|---|---|
Backup and restore RTO |
Best effort |
Best effort |
Best effort |
Best effort |
1h |
In-region disaster recovery RTO |
N/A |
Best effort |
Best effort |
Best effort |
1h |
Multi-region disaster recovery RTO |
N/A |
Best effort |
Best effort |
Best effort |
4h |
Multi-region with Secure Connect disaster recovery RTO |
N/A |
Best effort |
Best effort |
Best effort |
4h |
Tenant environment FQDNs
Ping Identity creates a separate FQDN (fully qualified domain name) for each of your tenant environments.
FQDN format
The FQDN of each tenant environment uses a naming convention based on a combination of these values:
| Name | Description | Example |
|---|---|---|
Sandbox base name |
A tenant sandbox base name you provide to your Ping Identity representative. |
mycompanysandbox |
Base name |
A tenant base name you provide to your Ping Identity representative. |
mycompany |
Data region abbreviation |
The data region your tenant environments are located in. |
usw1 |
Tenant environment type |
The type of tenant environment. |
staging |
-
For your sandbox[2] environments, the FQDN naming convention is:
<tenant-env-fqdn> = openam-<sandbox-base-name><sandbox-number>-<data-region-abbr>.forgeblocks.com
So, for a company with a sandbox base name "mycompanysandbox" using the London data location ("ew2") and with two sandbox environments, the tenant environment FQDNs would be:
-
openam-mycompanysandbox1-ew2.forgeblocks.com
-
openam-mycompanysandbox2-ew2.forgeblocks.com
-
-
For your development, UAT[1], and staging environments, the FQDN naming convention is:
<tenant-env-fqdn> = openam-<base-name>-<data-region-abbr>-<environment-type>.id.forgerock.io
So, for a company with a base name "mycompany" using the London data location ("ew2") and with two UAT environments, the tenant environment FQDNs would be:
-
openam-mycompany-ew2-dev.id.forgerock.io
-
openam-mycompany-ew2-uat.id.forgerock.io
-
openam-mycompany-ew2-uat2.id.forgerock.io
-
openam-mycompany-ew2-staging.id.forgerock.io
-
-
For your production environment, the FQDN naming convention is:
<tenant-env-fqdn> = openam-<base-name>-<data-region-abbr>.id.forgerock.io
So, for a company with a base name "mycompany" using the London data location ("ew2") the tenant environment FQDN would be:
-
openam-mycompany-ew2.id.forgerock.io
-
Confirm the FQDN in tenant settings
You can confirm a tenant environment’s FQDN by checking its tenant settings:
-
In the Advanced Identity Cloud admin UI, open the TENANT menu (upper right), then go to Tenant Settings > Details.
-
The tenant environment’s FQDN is displayed under the label Tenant Name.
FQDN placeholder in API examples
In the API examples throughout Advanced Identity Cloud documentation, the tenant environment FQDN is represented using the placeholder <tenant-env-fqdn>. The following is an API example that uses the placeholder:
$ curl \
--request GET 'https://<tenant-env-fqdn>/openidm/config/external.email' \
--header 'Content-Type: application/json' \
--header 'Accept-API-Version: resource=1.0' \
--header 'Authorization: Bearer <access-token>'