TLS, secrets, signing, trust, and encryption
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 v2.0 assertions and client-based access tokens.
Incoming SAML v2.0 assertions require trust relationships with the SAML v2.0 providers.
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.
By default, your Identity Cloud tenant uses a Google-managed SSL certificate for TLS encryption.
If you prefer, 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, see Configure a self-managed SSL certificate.
When you configure 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 Identity Cloud to log in to an external system, such as an OTP provider. But you need 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 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 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 Identity Cloud environment was running.
For more information, see Define and promote ESVs.
By default, Identity Cloud generates a set of secret IDs in each Identity Cloud realm. Each secret ID corresponds to functionality in Identity Cloud that requires a signing key or certificate. For a full list of secret IDs, see secret ID mappings.
Identity Cloud lets you override the generated secret IDs. 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, see Use ESVs for signing and encryption keys.
If your Identity Cloud tenant has trust relationships with one or more SAML v2.0 providers, the tenant might receive SAML assertions signed by a certificate. The certificate might itself be signed by a certificate authority (CA). For Identity Cloud to trust this type of SAML assertion, the CA’s public certificate must be installed in Identity Cloud.
You can add a CA’s public certificate to your Identity Cloud configuration by submitting a support request.