ForgeRock Identity Cloud documentation

The ForgeRock Identity Cloud is a comprehensive IAM service. Our service lets you deploy applications anywhere: on-premises, in your own private cloud, or in your choice of public cloud.

With ForgeRock Identity Cloud, you can manage the complete lifecycle of identities including:

And much more…​

ForgeRock is here to help you with your identity journey. You’ll have a dedicated team to help you achieve your goals. Find all the resources you need Backstage.

Our dedicated cloud engineering team monitors and manages your environment. We’ll help you with moving configuration, and with secrets management, between environments. Learn about moving configuration between environments.

Here are some things you can try in your development environment:

Once you’re ready to stage real users and applications in your tenant, start with these steps:

Identity Cloud provides three user interfaces (UIs) to help you manage your tenant:

① Identity Cloud admin UI
② AM admin UI (native console)
③ IDM admin UI (native console)

This is the primary UI, designed to handle most of the day-to-day tasks associated with managing your tenant. To get started, take a test drive.

These are secondary UIs, intended for specialist tasks when configuring AM and IDM in Identity Cloud. They let you access functionality not yet available in the Identity Cloud admin UI.

You don’t need separate credentials to access these UIs. If you are signed into the Identity Cloud admin UI, you can seamlessly switch from one UI to another.

Identity Cloud analytics dashboard provides a comprehensive snapshot of your Identity Cloud system usage. You can use the dashboard to gain valuable insights on your tenants:

At the top of the Identity Cloud analytics dashboard, there is a summary of total number of users, applications, and organizations in your realm. These realm usage totals are summarized as follows:

Below the realm usage totals, Identity Cloud analytics dashboard displays three trendline charts: user engagements, total users, and new users. These trendline charts are updated every two to three hours and are summarized as follows:

You can refer to a chart on the number of successful and failed journey outcomes within your realm on the Identity Cloud analytics dashboard. Scroll down the Identity Cloud analytics dashboard page to refer to the Journeys graph.

By default, the Identity Cloud analytics dashboard displays the aggregation of all successful and failed journeys on the Identity Cloud. These aggregations express four different types of information:

The Identity Cloud analytics dashboard also lets you filter the chart by journey type. The available journeys are listed on the Identity Cloud Journeys page and includes any custom journeys that you may have configured. For example:

The categories are:

The Journeys chart also lets you drill down at specific points on a trendline to access its details, or metric breakdown. Red lines indicate failed journeys. Blue lines indicate successful journeys.

For example, you can use the Metric Breakdown page to review the journeys for the selected date, sorted by a ranking of percentage failures (default). The percentage is calculated for each journey as the total outcomes passed or failed, and then sorted in descending order from the highest failed journey by percentage to the lowest failed journey by percentage.

The Metric Breakdown page also lets you sort the journeys by number ranking. Number indicates the actual number of successful or failed outcomes for each journey.

The following table provides an example of how the analytics dashboard ranks by percentage and by number:

The Identity Cloud analytics dashboard displays two additional widgets providing trendlines into your journeys: Top Five Journeys by Outcome and Top Five Journeys by Usage. The Top Five Journeys by Outcome widget displays the top five journeys ranked by percentage failed or successful. The default selection is Fail. You can change the selection to Success to display top five successful journeys.

The Top Five Journeys by Usage widget displays the top five most or least used journeys. By default, the most used journeys are selected. Each bar chart provides the percentage usage of the journey in the given time period based on the outcomes only. For each journey, the calculation is based on the total number of outcomes for the journey divided by the total number of all journey outcomes in the time period.

The analytics dashboard service provides key insights and trends with respect to successful or failed journey outcomes, number of users, user engagement, number of new users (sign-ons), applications, and organizations. By leveraging this functionality, ForgeRock customers can better understand their usage of the Identity Cloud. This functionality also allows ForgeRock to maintain accurate billing information with respect to such use.

All data ForgeRock collects for the purposes of providing the analytics dashboard service is anonymized using industry standard practices. The purpose is to ensure that the data does not contain any personally identifiable information, and further, so it cannot be re-identified. This includes, but is not limited to, a one-way SHA-256 hashing function that returns a hexadecimal representation of a UUID. This ensures that no personally identifiable information is used by ForgeRock, or any other third-party or system.

When you sign up for Identity Cloud, you specify the region where you want your data to reside. This is key in helping you meet data residency compliance requirements while letting you place data as close to your users as possible.

Identity Cloud uses pre-configured ranges of IP addresses in Google Cloud Platform (GCP) regions. The IP addresses are not exclusive to ForgeRock.

ForgeRock supplies tenant URLs for your development, staging, and production tenant environments. All tenant URLs include the organization name and tenant name you provided when you signed up.

Identity Cloud uses region abbreviations in the production tenant URLs to indicate the region where data resides. Refer to the Regions section for the abbreviations.

For example, "usw1" is the abbreviation for the us-west1 region. Suppose your production tenant environment URL is:

https://openam-mycompany-mytenant-usw1.id.forgerock.io

The presence of the region abbreviation "usw1" as part of the URL indicates that your data resides in the us-west1 region.

The tables in this section show all the region abbreviations for the data regions that Identity Cloud uses.

They also indicate secondary backup regions when available.

Each Identity Cloud account includes a development, a staging, and a production tenant environment. These three environments let you build, test, and deploy your IAM applications:

Identity Cloud uses a promotion model to move configuration changes through the three environments.

The development environment is mutable. This means that you can make configuration changes to the environment through one of the admin UIs or through the REST API.

By contrast, the staging and production environments are not mutable. This means that you cannot make configuration changes to these environments directly. Instead, you must move the changes from the development environment to the staging environment by running a promotion, then move the changes from the staging environment to the production environment by running a further promotion.

In situations where you want a configuration value (such as an authentication token) to be distinct in each environment, you can set the value as an ESV in each environment, then insert the ESV placeholder into your configuration, then move the configuration to your staging and production environments by running sequential promotions. Refer to Use ESVs in configuration placeholders.

Sandbox tenant environments are standalone environments that are separate from your development, staging, and production tenant environments. They behave similarly to your development environment, but allow you more freedom to test various use cases. You can run experiments without being concerned about accidentally promoting your changes to your staging or production environments.

For example, perhaps you want to create some user journeys and test them before deciding which one you’d like to use in your development environment. You can safely do this in a sandbox environment because nothing in these environments is part of the promotion process. This means you don’t need to worry about cleaning up unused user journeys. You can extract any configuration from your sandbox environment using the REST APIs, then post it to your development environment.

There are some important guidelines to note when using sandbox environments. In particular, these environments should not be used for load testing, and they should not contain personally identifiable information (PII):

The Identity Cloud admin UI provides you a unified view of all the customer, workforce, and device profiles in your tenant. Use the Identity Cloud admin UI to manage all aspects of your tenant including: realms, identities, applications, user journeys, and password policy.

You can review tenant details and access global settings for your tenant by opening the account menu in the top right of the Identity Cloud admin UI, then clicking the Tenant Settings menu option.

Click the Admins tab on the Tenant Settings page to access options to:

The tenant provisioning process initially creates a single administrator, known as the tenant administrator. A tenant administrator is authorized to configure realm and tenant settings, and to invite others to become tenant administrators. All tenant administrator identities get the same realm permissions, and these are not configurable.

You can invite, view, or edit tenant administrators by opening the account menu in the top right of the Identity Cloud admin UI, then navigating to Tenant Settings > Admins.

Tenant administrators access their sign-in page using a URL that specifies the realm as a forward slash:

Upon successful authentication, a tenant administrator is automatically switched to the Alpha realm.

Multiple failed authentication attempts cause Identity Cloud to lock out a tenant administrator. For information about how to unlock an administrator’s account, refer to Unlock a tenant administrator’s account.

In the Identity Cloud admin UI, open the Tenant menu (upper right), and click your username.

On your tenant administrator profile page:

Send invitations to people when you want to authorize them to manage settings for your tenant.

After the invitee completes the instructions in the invitation email, the invitee becomes an administrator.

From the tenant administrators list, you can invite new tenant administrators, deactivate tenant administrators, or delete tenant administrators.

If Identity Cloud locks out one of your company’s tenant administrators due to multiple failed login attempts, the account can be unlocked.

If your organization has multiple tenant administrators, another tenant administrator can unlock the account:

If your organization does not have multiple tenant administrators, submit a support ticket. Go to Backstage, and click Support.

2-step verification, also known as multifactor authentication (MFA), prevents unauthorized actors from signing in as a tenant administrator by asking for a second factor of authentication.

Identity Cloud provides tenant administrators with the following second factor options:

Environment secrets and variables (ESVs) let you individually configure the development, staging, and production environments in your Identity Cloud tenant.

Use variables to set values that need to be different for each tenant environment. For example, an authentication node might need one URL in your development environment, but a different URL in your production environment.

Use secrets to set values that need encrypting. The values may or may not need to be different for each tenant environment. For example, an MFA push notification node might need an authorization password to use an external SMS service.

To use the API, see the following Identity Cloud API endpoints:

To authenticate to the API, refer to Authenticate to ESV API endpoints.

To authenticate to ESV API endpoints, use an access token.

In addition to the default fr:idm:* OAuth scope, there are several additional OAuth scopes that can be used with the ESV API endpoints when you create an access token:

When one or more ESVs have been created or updated by any of the tenant administrators, the ESV entry screen will display a blue banner at the top to tell you how many updates are waiting to be applied:

To apply any pending updates:

Identity Cloud lets you reference ESVs from configuration placeholders. This lets you use different configuration values for the development, staging, and production environments at run time.

For example, suppose you wanted to set a different email sender for each environment. You would set the configuration value of the email sender to an ESV, with different values in each environment; for example, dev-mycompany@example.com (development), staging-mycompany@example.com (staging), and mycompany@example.com (production). Then, you would insert the ESV configuration placeholder into your configuration instead of a literal value.

If you want to add more ESVs later, repeat the steps above, and use a further series of promotions.

If you update an ESV referenced by a configuration placeholder, you also need to restart Identity Cloud services. This substitutes the updated secret or variable into the corresponding configuration placeholder:

An example of using a variable would be to define a URL that a user is redirected to after logging in. In each environment, the URL would need a different value; for example, dev-www.example.com (development), staging-www.example.com (staging), and www.example.com (production).

To define and promote the variable:

The following illustration demonstrates the process:

Identity Cloud lets scripts access ESVs directly, without the need for you to restart Identity Cloud services or request a promotion first.

To access an ESV with the name esv-my-variable in an AM script, use:

For more information on using the systemEnv binding, refer to ESVs in AM scripts.

To access an ESV with the name esv-my-variable in an IDM script, use:

For more information on using the identityServer variable, refer to The identityServer variable.

Identity Cloud lets you store signing and encryption keys in ESV secrets, then map them to secret IDs. Each secret ID represents an authentication feature in Identity Cloud, such as signing OAuth 2.0 client access tokens.

Identity Cloud can directly access keys stored in a mapped ESV secret, there is no need to restart Identity Cloud services.

You can rotate keys stored in a mapped ESV secret by adding new secret versions to the ESV. The key in the latest secret version is used to sign new access tokens, then subsequently validate them. Keys in older secret versions (that are still enabled) are still used to validate existing access tokens.

Secret IDs (also known as secret purposes) represent authentication features in Identity Cloud that need a signing or encryption key. For example, to sign an OAuth 2.0 client access token with an HMAC key, you would use the secret ID am.services.oauth2.stateless.signing.HMAC.

For a full list of secret IDs, refer to Secret IDs.

In each realm, each secret ID is mapped to a default secret key. You cannot access these default secret keys. However, you can override the default key mappings. To do this, map a secret ID to an ESV secret in a realm’s ESV secret store.

To store a key in an ESV secret, then map it to a secret ID:

You can rotate keys stored in a mapped ESV secret by manipulating the enabled status of its secret versions:

The following knowledge base article describes how to rotate SAML2 certificates using ESVs: https://backstage.forgerock.com/knowledge/kb/article/a47544526.

Identity Cloud lets you add placeholders to your configuration so you can reference the value of an ESV variable instead of defining a static value.

For example, if you created an ESV variable with the name esv-email-provider-port, you could reference its value by adding a placeholder of {"$int" : "&{esv.email.provider.port}"} to your configuration.

To set a default value in a configuration placeholder, include it after a vertical bar. For example, the following expression sets a default email provider port of 465: {"$int" : "&{esv.email.provider.port|465}"}. If no ESV is set, the default value of 465 is used instead.

If you add a placeholder to your configuration, and do not set a corresponding ESV or specify a default value, you will not be able to complete a successful promotion.

A configuration property can include a mix of static values and placeholders. For example, if you set esv-hostname to id, then &{esv.hostname}.example.com evaluates to id.example.com.

You can view placeholders in the Identity Cloud admin UI; however, they are read only.

You can manage placeholders using the REST API. Refer to Manage configuration placeholders using the API.

Identity Cloud lets you run self-service promotions to move configuration between a sequential pair of tenant environments; either from the development environment to the staging environment (staging promotion), or from the staging environment to the production environment (production promotion).

You can run promotions using the following options:

The environments in a sequential pair of environments are referred to as the lower environment (the configuration source), and the upper environment (the configuration destination); the terms lower environment and upper environment therefore refer to different environments, depending on whether you are running a staging promotion or a production promotion:

Before you run a promotion, you must lock the lower and upper environments. This prevents anyone else from locking either of those environments, which ensures only one promotion can be run at the same time in the same set of development, staging, and production environments.

Locking the lower and upper environments also blocks access to the ESV API in those environments. This prevents anyone else from accidentally disrupting the promotion by manipulating ESV configuration values. If the lower environment is also the development environment, then most Identity Cloud API endpoints are also restricted.

When a promotion is complete, you must unlock the lower and upper environments to return the environments back to full functionality.

When you run a promotion, Identity Cloud performs integrity checks on your static configuration to protect the stability of the upper environment.

Before you run any promotions API requests, you must know which tenant environment is the lower environment and which is the upper environment. Refer to Lower and upper environments.

The API uses a pull model to promote configuration, so most API commands need to be run against the upper environment.

When you are ready to run a promotion, you can optionally perform a dry run first. This lets you identify any problems with missing ESVs or encrypted secrets, before you run a full promotion.

To use the promotions API, refer to the following Identity Cloud API endpoints:

The following diagram summarizes how promotions API commands are used to run a promotion. Refer to Steps to run a promotion.

You need to check the lock state and the promotion status several times during a promotion, and analyze the responses in order to decide how to proceed.

To revert a promotion, raise a support ticket:

To resolve environment errors that are preventing promotions, raise a support ticket:

Before you run a promotion using the UI, you must know which tenant environment is the lower environment and which is the upper environment. Refer to Lower and upper environments.

The UI uses a push model to promote configuration, so you need to run a promotion from the UI in the lower environment. However, you also need to have a tenant administrator account in the upper environment, as the UI in the lower environment needs to authenticate to the upper environment.

When a promotion is complete, you can view a report in the lower environment. You can also view the report in the upper environment.

In the lower environment, the promotions UI lets you:

This lower environment functionality exists in your development and staging environments only. It does not exist in your production environment, as that environment does not send promotions to another environment.

In the upper environment, the promotions UI lets you:

This upper environment functionality exists in your staging and production environments only. It does not exist in your development environment, as that environment does not receive promotions from another environment.

When you run a promotion and lock the upper and lower environments, the UI restricts some functionality under Tenant Settings > Promotion until the environments are unlocked.

ForgeRock is replacing support-assisted promotions with self-service promotions. Instead of raising a support ticket to promote configuration to your tenant environments, you’ll be able to promote configuration yourself. In addition, it will be possible for you to view and edit configuration placeholders in all Identity Cloud APIs.

To introduce self-service promotions, ForgeRock needs to migrate the configuration of some customers.

If your development environment does not have any ESVs by the migration cutoff deadline (Tuesday, November 22, 2022), your configuration will not need to go through a migration process, and your environments will be enabled automatically for self-service promotions. You will not need to take any action, and you do not need to finish reading this FAQ.

Alternatively, if your development environment does have ESVs by the migration cutoff deadline (Tuesday, November 22, 2022), your configuration will need to go through a migration process. You will be given your own specific migration date and time. After the configuration has been migrated, your environments will be enabled for self-service promotions. Please finish reading this FAQ to fully understand the migration process and the actions you may need to take.

Identity Cloud handles configuration placeholders for support-assisted and self-service promotions differently:

If your development environment has any ESVs, ForgeRock will assume that your configuration has corresponding placeholders, and that your configuration will need to be migrated so that it is compatible with self-service promotions.

During the migration process, ForgeRock will permanently substitute the actual placeholders into your configuration, then enable self-service placeholder management in your environments.

Your development environment will need to be migrated, as will your sandbox environment, if you have one.

Your sandbox environment will be migrated in the same way as your development environment, to make sure that all environments are consistent.

Once the migration of your development environment is complete, self-service configuration management will also be enabled for your staging and production environments.

You may maintain an external copy of your Identity Cloud configuration using CI/CD automation, source code management, or simple scripts. If so, there is a danger that after migration, the old external copy of your configuration (which doesn’t contain literal placeholders) could accidentally overwrite the newly migrated Identity Cloud configuration (which contains literal placeholders). You will therefore need to take additional action immediately after your Identity Cloud configuration has been migrated; you will need to replace the external copy of your configuration with a download of the newly migrated Identity Cloud configuration, so that your external copy contains literal placeholders.

If you do not maintain an external copy of your Identity Cloud configuration, then you do not need to take any additional action.

ForgeRock recommends that, in the first instance, you reach out to the third party that developed your Identity Cloud service. Failing that, for assistance from ForgeRock professional services, please raise a support ticket.

You will be assigned a date and time for your migration. The notification will appear in a yellow box at the top of the Identity Cloud admin UI in your development and sandbox environments, with this message:

Yes, you can raise a support ticket to change the date and time:

The Identity Cloud admin UI will be fully functional again, and will no longer show the message "Tenant Locked" in the top left of the screen.

Yes, refer to Self-service promotions migration process flow.

Refer to Introduction to configuration placeholders.

ForgeRock has listened to Identity Cloud customers, and found that many customers want to define configuration placeholders and run promotions without a support ticket, and consider this of paramount importance. Additionally, ForgeRock found that many customers rely heavily on API, and do not use the UI as frequently.

With this in mind, ForgeRock decided to introduce self-managed promotions using API, before full UI support is available.

Refer to Introduction to self-service promotions.

ForgeRock has tested the self-service promotions API internally to ensure that the transition to self-service promotions is as seamless as possible. Our support engineers have been using the API for customer promotions since 7th June 2022.

For background on the process of migrating to self-service promotions, see Self-service promotions migration FAQ.

The following diagram summarizes the migration process flow:

Identity Cloud provides service accounts to let you request access tokens for most REST API endpoints; for example, you may need an access token to use the REST API endpoint /openidm/managed/alpha_user to get a list of identities.

You create a new service account in the Identity Cloud admin UI, then use the JWT profile for OAuth 2.0 authorization grant flow to obtain an access token from it. You can then use the access token as a bearer token in the Authorization HTTP header for each API request.

Only a tenant administrator can create, modify, or delete service accounts, and only by using the Identity Cloud admin UI; refer to Manage service accounts using the UI. It is not possible for any user, even a tenant administrator, to create, modify, or delete service accounts using the REST API.

You create service accounts in each environment; they are not promotable.

When you create a service account, you choose which scopes it can grant to the access tokens it creates. You should always choose the minimum number of scopes needed.

To get an access token using a service account, refer to Authenticate to Identity Cloud REST API with access token.

Identity Cloud provides monitoring endpoints you can use with Prometheus.

You must obtain API credentials to authenticate to these endpoints. See Obtaining API Credentials.

You can download and run a Docker-based example of a Grafana dashboard. The demo requires that you have Docker Desktop installed, and requires macOS.

To try the demo:

Identity Cloud provides audit and debug logs to help you manage your tenant:

Identity Cloud stores logs for 30 days. Use the /monitoring/logs endpoint to access the stored data.

Identity Cloud makes browsing the logs easier by storing them in various sources.

The following knowledge base article lists the sources available and describes their purpose: What logging sources are available in Identity Cloud?

To view a list of the available sources, use the /monitoring/logs/sources endpoint.

Example request:

Example response:

Identity Cloud returns the available sources in the result array.

To access the stored logs for a source, use the /monitoring/logs endpoint, specifying the source as a parameter.

Example request:

Example response:

Identity Cloud returns the available logs in the result array.

Results are in JSON format or plaintext, depending on the source you request.

To tail, or get the latest entries in the stored logs for a source, use the /monitoring/logs/tail endpoint with the source as a parameter.

The first call to the tail endpoint returns results from the last 15 minutes. Subsequent calls return logs from:

You can request results in JSON format or plaintext. One source can have both JSON and plaintext logs; for example, when you request am-everything.

Example request:

Example response:

You can specify multiple sources in a single call. Example request:

All log events for an external request into Identity Cloud are assigned the same unique transaction ID. The x-forgerock-transactionid response header holds the transaction ID:

To filter the logs for a specific transaction ID, add the transactionId parameter to your API request; for example:

Example response:

The following knowledge base article describes how to add additional fields to an audit request: How do I extend auditing in Identity Cloud to include additional fields?

To reduce unwanted stresses on the system, Identity Cloud limits the number of requests you can make to the /monitoring/logs endpoint in a certain timeframe:

These limits apply per environment, so your development, staging, and production environments each have their own quota.

The following rate limit notification response headers are sent for each request to the /monitoring/logs endpoint:

Identity Cloud uses email provider configuration to support email-dependent end-user journeys. For example, registration and password reset end-user journeys usually include an email component.

By default, Identity Cloud configures the email provider with default values to connect to a built-in SMTP server. This lets you quickly create and test email-dependent journeys in your tenant development environment using the ready-to-use email templates. No rate limiting is applied to password reset emails, or any emails sent by the built-in SMTP server. This means an attacker can potentially spam a known user account with an infinite number of emails, filling that user’s inbox. In the case of password reset, the spam attack can obscure an actual password reset attempt.

In your staging and production tenant environments, you must configure the email provider with values to connect to your own external SMTP server.

In your staging and production tenant environments, configure the email provider to use your own external SMTP server using the UI or the API.

If you need to revert the email provider to use the built-in SMTP server:

Identity Cloud provides preconfigured email templates for common end-user journeys.

You can customize email templates using Markdown language. Identity Cloud uses a parser to let you preview your markup.

Cross-origin resource sharing (CORS) lets user agents make cross-domain server requests. In Identity Cloud, you can configure CORS to allow browsers from trusted domains to access Identity Cloud protected resources. For example, you might want a custom web application running on your own domain to get an end-user’s profile information using the Identity Cloud REST API.

By default, CORS is configured to let the ForgeRock SDKs access Identity Cloud. You can add additional CORS configurations that let other APIs or SDKs access Identity Cloud.

Configure CORS by using the Identity Cloud admin UI, as described in the following sections.

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.

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

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.

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.

Realms are administrative units that group configurations and identities together.

Realms let you manage different sets of identities and applications within the same Identity Cloud tenant. Each realm is fully self-contained and operates independently of other realms within a tenant.

The identities and applications in one realm cannot by default access those in another realm; however, you can grant conditional access across realms.

A typical example of realm management is when a company divides its identities into two realms: one for employees and one for customers, each having a distinct set of identities and registered applications. The realms provide the means to keep customers from accessing employee information, while allowing employees conditional access to customer information.

When you’re satisfied with your changes, click Save.

Overriding realm authentication attributes is useful when you want to adjust the core authentication properties that apply to a realm. For example, you might want to extend the time limit for responding to an authentication verification email. Use the AM admin UI to make this kind of change.

For detailed property information, refer to Core authentication attributes.

Switch realms when you want to access identities or applications registered to a realm other than the current realm.

The Alpha and Bravo realms are the two default realms that are included as part of an Identity Cloud tenant. These realms are configurable, unlike the top-level realm that Identity Cloud configures for tenant administrator identities.

The Alpha and Bravo realms are nearly identical, with the exception of delegated administration.

End users access their sign-in page using a URL that specifies the realm they belong to. For example:

Tenant administrators cannot authenticate using these realm-specific login URLs, refer to Tenant administrator sign-in.

In the Alpha realm you can set up internal roles for delegated administration using a custom set of privilege attributes.You can then assign those internal roles to users so that Alpha realm users can act as delegated administrators and perform actions on the custom set of attributes specified by the role.

The Bravo Realm does not support delegated administration.

Access Identity Cloud through a customer-friendly URL by configuring a custom domain name. For example, replace the default forgerock.io domain with your own company name or brand.

Consider the following points when you customize a domain name: