TLS, secrets, signing, trust, and encryption
PingOne Advanced Identity Cloud was built with security in mind:
-
Incoming network traffic is always encrypted over TLS.
-
Secrets — for example, credentials to connect to external services—can be specified in your developer, staging, and production environments.
-
Keys and certificates are used to generate, sign, validate, and encrypt tokens, such as SAML 2.0 assertions and client-based access tokens.
-
Incoming SAML 2.0 assertions require trust relationships with the SAML 2.0 providers.
-
Advanced Identity Cloud data is encrypted at rest.
This page describes the default implementations for each of these security factors. It also describes customization options, if they’re available.
TLS encryption
By default, your Advanced Identity Cloud tenant uses a Google-managed SSL certificate for TLS encryption.
If you prefer, Advanced Identity Cloud lets you use your own, self-managed SSL certificate instead of using the Google-managed SSL certificate.
For more information about configuring your tenant to use a self-managed certificate, refer to Self-managed SSL certificates.
Secrets
When you configure Advanced Identity Cloud, the secrets you provide in your development environment normally do not change when you promote your environment to staging and production. But, in some situations, you might want the three environments to use different secrets.
For example, you might want Advanced Identity Cloud to log in to an external system, such as an OTP provider. But you need Advanced Identity Cloud to use different credentials depending on whether it’s accessing the OTP provider from the development, staging, or production environment.
Environment secrets and variables (ESVs) let you configure different secrets in your Advanced Identity Cloud development, staging, and production environments. In the preceding example, instead of hard-coding a single set of credentials for the OTP provider in the Advanced Identity Cloud admin UI, you could configure ESVs that hold the credentials. Then, the desired credentials to the OTP provider would be used depending on which Advanced Identity Cloud environment was running.
For more information, see Define and promote ESVs.
Signing keys and certificates
By default, Advanced Identity Cloud generates a set of secret labels in each Advanced Identity Cloud realm. Each secret label corresponds to functionality in Advanced Identity Cloud that requires a signing key or certificate. For a full list of secret labels, refer to Secret labels.
Advanced Identity Cloud lets you override the generated secret labels. First, create an ESV secret that holds the key or certificate. Then, map the secret in the secret store of the desired realm.
For more information, refer to Use ESVs for signing and encryption keys.
Trust relationships with SAML 2.0 providers
If your Advanced Identity Cloud tenant has trust relationships with one or more SAML 2.0 providers, the tenant might receive SAML assertions signed by a certificate. The certificate might itself be signed by a certificate authority (CA). For Advanced Identity Cloud to trust this type of SAML assertion, the CA’s public certificate must be installed in Advanced Identity Cloud.
You can add a CA’s public certificate to your Advanced Identity Cloud configuration by submitting a ticket to Backstage Support.