Identity Cloud

TLS, secrets, signing, trust, and encryption

Identity Cloud was built with security in mind:

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 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.

Signing keys and certificates

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, refer to Secret IDs.

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.

Trust relationships with SAML 2.0 providers

If your 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 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 ticket to ForgeRock Support.

Encrypted data at rest

In Identity Cloud, your tenant includes a unique data encryption key. All Identity Cloud data that’s stored at rest is encrypted with this key.

You cannot use your own encryption key to encrypt Identity Cloud data.

Copyright © 2010-2023 ForgeRock, all rights reserved.