ForgeRock Identity Cloud Documentation

Single-page edition

All Identity Cloud Docs on a single HTML page. Use this for text searches, or to make a PDF.

Identity Cloud Docs

Overview

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…​

Support and customer success

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.

Getting Started with ForgeRock Identity Cloud

To sign in to Identity Cloud for the first time, you’ll need information in the confirmation email your ForgeRock representative sent you. If you haven’t submitted a registration request and received a confirmation email, then contact your ForgeRock representative.

1 - Sign in to Identity Cloud

  1. In a supported web browser, go to the URL indicated in your registration confirmation email.

  2. Use the username and password in your registration confirmation email.

2 - Know your tenant

  1. Take 5 minutes to read about the Identity Cloud and its capabilities.

  2. Take 5 minutes to read about your tenant.

3 - Take a test drive

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

  1. Create a user profile.

  2. Create an external role for your user.

  3. Add an application to your identity platform.

  4. Set up a basic login end-user journey.

  5. Sign out of your tenant administrator session, then be the end-user:

    1. Using a browser, go to your tenant URL.

    2. Sign in as the test user you created.

4 - Get going

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

  1. Take some time to read up on how your engineering environments work.

  2. To provision your tenant, import identity profiles to your tenant.

  3. Invite others to be tenant administrators.

  4. Add an application to your tenant.

  5. Sync your application users with users in your tenant.

  6. Use the ForgeRock SDK to set up authentication.

  7. Set up a login end-user journey.

Admin Consoles

Overview

Identity Cloud provides access to ForgeRock AM Admin UI and IDM Admin UI. These native consoles let you leverage functionality not yet available in the Admin UI.

You don’t have to have separate credentials to access either AM Admin UI or IDM Admin UI. If you are signed into your identity platform, you can seamlessly switch from one Admin UI to another.

AM Admin UI

Use the AM Admin UI when you want to register SAML applications, for example.

In the Identity Cloud Admin UI, click Native Consoles > Access Management.

am native console

Browse the AM Docs for
information about AM capabilities:
 
Authentication Trees (Journeys)
Service Management
OAuth2 Clients
SAML Applications
IG Protected Apps
Java Agents
Web Agents

IDM Admin UI

Use the IDM Admin UI when you want to create a device profile, for example, or map your identities to identities stored in an external resource.

In the Identity Cloud Admin UI, click Native Consoles > Identity Management.

idm native console

Browse the IDM Docs for
information about IDM capabilities:
 
Add Connector
Create Mapping
Manage Roles
Add Device
Configure Registration
Configure Password Reset
Manage Users
Configure System Preferences

Data Regions

Overview

When you create your tenant, you select 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 Google Cloud Platform (GCP) pre-configured ranges of IP addresses per region. The IP addresses are not exclusive to ForgeRock. You can narrow the expected range by selecting the appropriate region.

Your default tenant URL includes your company name, region abbreviation, your tenant ID, and the forgerock.io domain. Compare your tenant URL to the examples in this table. Be sure your tenant URL reflects where your data resides.

Regions

Location group Location Region Abbreviation Example tenant URL

United States

Oregon
Los Angeles
Iowa
South Carolina
North Virgina

us-west1
us-west2
us-central1
us-east1
us-east4

usw1
usw2
usc1
use1
use4

http://usw1-dev.id.forgerock.io
http://usw2-dev.id.forgerock.io
http://usc1-dev.id.forgerock.io
http://use1-dev.id.forgerock.io
http://use4-dev.id.forgerock.io

Canada

Montréal

northamerica-northeast1

nane1

http://nane1-dev.id.forgerock.io

Brazil

São Paulo

southamerica-east1

sae1

http://sae1-dev.id.forgerock.io

Europe

London
Belgium
Netherlands
Zurich
Frankfurt
Finland

europe-west2
europe-west1
europe-west4
europe-west6
europe-west3
europe-north1

ew1
ew2
ew3
ew4
ew6
en1

http://ew1-dev.id.forgerock.io
http://ew2-dev.id.forgerock.io
http://ew3-dev.id.forgerock.io
http://ew4-dev.id.forgerock.io
http://ew6-dev.id.forgerock.io
http://en1-dev.id.forgerock.io

Asia

Singapore
Jakarta
Hong Kong

asia-southeast1
asia-southeast2
asia-east2

ase1
ase2
ae2

http://ase1-dev.id.forgerock.io
http://ase2-dev.id.forgerock.io
http://ae2-dev.id.forgerock.io

Australia

Sydney

australia-southeast1

ausse1

http://ausse1-dev.id.forgerock.io

Tenant Environments

Overview

Each Identity Cloud tenant includes three separate environments that let you build, test, and deploy your IAM applications:

Tenant Environment Description

Development

Used for building and adding new features.
Limit the number of identities to 10,000.

Staging

Used for testing development changes, including testing applications under realistic settings such as stress tests and scalability tests.

Production

Used for deploying applications into operation for end users.

Identity Cloud also offers standalone sandbox environments.

Environment configuration

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

The development environment is mutable. This means that you can easily make configuration changes to the environment, either through the browser UI 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, the ForgeRock support team promotes the changes from the development environment. This is known as a configuration promotion and is done on a request basis by submitting a support ticket.

In situations where you want a configuration value (such as an authentication token) to be distinct in each environment, the ForgeRock support team can also set this up. This is known as a configuration intervention and is also done on a request basis by submitting a support ticket.

Tenant Environment Mutable Making Configuration Changes Setting Distinct Environmental Configuration Values

Development

UI or REST API

Configuration intervention request

Staging

Configuration promotion request

Production

Configuration promotion request

Sandbox Environments

Overview

Sandbox environments are standalone environments that are separate from your tenant environments. They behave similarly to the development environment in your tenant, but allow you more freedom to test various use cases. You can run experiments without being concerned about accidentally promoting your changes to your tenant 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 tenant environments. 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 also extract any configuration from your sandbox environment using the REST APIs, then post it to your tenant development environment.

Contact your ForgeRock representative if you are interested in adding a sandbox environment to your subscription.

Sandbox usage guidelines

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):

Feature Description

Production use

No

Static & dynamic configuration

Mutable via the UI and REST APIs

Configuration promotion

No

Max number of identities

10,000

Log retention

1 day

Monitored via Statuspage.io

No

SLA

None

Personally identifiable information (PII)

No

Load testing

No

Level of support

None

Tenant Settings

Overview

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.

View tenant details

  1. In the Identity Cloud Admin UI, open the Tenant menu (upper right).

    150

  2. Click Tenant Settings > Details.

    The Tenant Name is the identifier assigned to the tenant during onboarding and registration. This identifier is not configurable.

You’ll need these artifacts for making API calls to AM, or for extracting log data.

  1. In the Identity Cloud Admin UI, open the Tenant menu (upper right).

    150

  2. Click Tenant Settings > Global Settings.

    • Server
      The name of the iPlanetDirectoryPro cookie for your tenant.
      You can copy and paste this in a variety of calls in AM. (Example: OAuth 2.0 Auth Code flow)

    • Log API Keys
      You’ll need this to extract log data.

      • Click On, then click the arrow.

      • In the Log API Keys dialog box, click + New Log API Key.

      • In the New Log API Key dialog box, provide a name, and then click Create key.

      • Identity Cloud generates an api_key_id and an api_key_secret for you to copy and paste.

      • Click Done.

Customize a UI theme

You can use your own logo and preferred colors in the UI that your app users will see.

  1. In the Identity Cloud Admin UI, click the realm name to expand the settings menu.

  2. Go to Realm Setting > Theme.

    • Realm Logo URL: Logo to use for all end-user UIs including consent pages and application pages. This URL can be overridden in the client application profile.

    • To customize the color of any of the following, enter a hexadecimal color code:

      • Sign-in Background Color

      • Button Color

      • Button Active Color

      • Button Text

    • Button Radius: To customize the size of the button radius, slide the slider to the right to make the button larger. Slide it to the left to make the button smaller.

    • (Optional) Sign-In Background Image: Enter the URL of an image you want to display in the background.

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

Tenant Administrator Settings

Overview

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 administrator sign-in

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

  • https://<tenant-name>.forgeblocks.com/login/?realm=/#/

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

Edit your own tenant administrator profile

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

150

On your tenant administrator profile page:

  • To edit your name or email address, click Edit Personal Info.
    Provide information, then click Save.

  • In the Account Security card:

    • To change your username, click Update.

      • Enter your current password, then click Next.

      • Enter your new username, then click Next.
        You’ll receive an email confirming your username has been changed.

    • To change your password, click Reset.

      • Enter your current password, then click Next.

      • Enter your new password, then click Next.
        You’ll receive an email confirming your password has been changed.

  • By default, 2-Step Verification is enabled.
    For more information, see Manage tenant administrator 2-step verification.

Manage tenant administrator 2-step verification

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

Identity Cloud provides two ways admins can sign in with a second factor:

When you sign in as a tenant administrator for the first time, Identity Cloud offers you choices, and guides you through the device registration process.

During registration, Identity Cloud displays 10 verification codes. Be sure to copy the codes and store them in a secure location.

  • You’ll use the verfication codes as recovery codes if you cannot use your registered device to sign in.

  • You can use each verification code only once. Then, the code expires.

  • If, for some reason, you need to re-register a device, first delete your previously registered device.

Change 2-Step verification options

  1. Open your tenant administrator user profile.
    In the Identity Cloud Admin UI, open the Tenant menu and choose your tenant administrator username.

  2. On your tenant administrator user profile page, find 2-Step Verification and click Change.

    The 2-Step/Push Authentication page lists devices you’ve registered for MFA.

    To delete a device, click its More () menu, and choose Delete.

    • When you delete a device from the list, 2-step or push authentication is disabled. You cannot undo the delete operation.

    • Once you sign out and attempt to sign back in again, you will be asked if you want to set up a second factor.

Invite other tenant administrators

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

  1. In the Identity Cloud Admin UI (upper right), open the Tenant menu.
    150

  2. Click Invite admins.

  3. In the Invite Admins dialog box, enter a comma-separated list of email addresses for the people you want to authorize.

  4. Click Send Invitations.
    Identity Cloud sends an email to each addressee. The invitation will contain instructions for the addressee to set up their administrator account.

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

By default, new administrators are authorized with the same permissions as the tenant administrator.

View the tenant administrators list

From the tenant administrators list you can invite new tenant administrators, view a tenant administrator’s profile, deactivate, or delete a tenant administrator.

  1. In the Identity Cloud Admin UI, click the tenant name to expand the settings menu.

  2. Click Tenant Settings > Admins.

    • To invite a new tenant administrator, click Invite Admins.

    • To deactivate a tenant administrator, click Active, then click Deactivate.
      When you deactivate a tenant administrator, their status changes, but they remain on the tenant administrators list.

    • To view a tenant administrator’s details, click More (). Tenant administrator details are not configurable on this page. You can edit a tenant administrator’s user profile on the Manage Identities page.

    • To delete a tenant administrator, click Delete admin.

      When you delete a tenant administrator, their username is removed from the tenant administrators list, and tenant administrator permissions are removed from their user profile. This operation cannot be undone!

Promote Configuration

Overview

The Identity Cloud promotion process lets you move your configuration changes securely from one tenant environment to another.

For more background on tenant environments, see Tenant Environments.

To promote configuration changes

  1. Go to the Backstage website, and click Support.

  2. On the ForgeRock Support page, click New Ticket.

  3. On the New Ticket page, choose Identity Cloud: Config Request.

  4. In the Request Type dialog box, provide:

    • Hostname: Enter the your tenant FQDN.
      Example: <TenantName>-<Region>-<CompanyName>.forgerock.io.

    • What would you like to do?

      • Choose Configuration promotion if you want to promote configuration, or if you want to add new ESV placeholders to your development environment configuration.

        What is the target environment for the promotion?

        Choose the option that best describes the target of your promotion.

        • Dev

        • Dev → Staging

        • Staging → Prod

        Who is the primary contact?

        Provide the first and last name of a person authorized to communicate with ForgeRock staff regarding this promotion request.

        Are there any "Environment Secrets and Variables"?

        If the promotion has a feature that requires variables or secrets, add the following to the description for each variable or secret:

        • Enter the secret or variable name set in advance.

        Secrets and variables can be managed using the following options:

        • Enter the name and path to the corresponding environment configuration attribute for the promoted feature.

      • Choose Restore from backup if you want to revert to a previous backup configuration.

        What is the environment name?

        Choose Development, Staging, or Production.

        What is the date of the backup you would like to restore from?

        Enter a date using the format YYYY-MM-DD.
        For example, to indicate December 31, 2021, enter 2021-12-31.
        The Support team restores the most recent backup taken before the date you specify.

  5. Click Submit.

ForgeRock promotes one step at a time. We’ll ask you to check and confirm the staging environment status before we promote the configuration to the production environment.

Promotion process FAQs

What kind of configuration changes can my company make?

For the purposes of promotion, ForgeRock draws a clear line between dynamic and static configuration.

Dynamic configuration changes occur automatically when your application end users use Identity Cloud features. For example, when they configure applications or add users in the Identity Cloud Admin UI, the changes take effect immediately in the development, staging, or production environments.

Static configuration changes occur only when authorized administrators make changes in the development environment, or when configuration changes get promoted to another environment. Only ForgeRock SREs can promote static configuration from development to staging and production environments.

The following tables summarize the types of configuration changes possible, and whom you can authorize to make changes:

Identity Cloud UI Configuration
Feature Dynamic
(devops)
Static
(promotion)

Custom domain names

  • DNS aliases

  • FQDN mappings

  • Cookie domains

  • Base URL service

Gateways & Agents

  • Native/SPA

  • Web (node.js, Java)

  • Service (m2m)

Journeys

Custom themes

Identities

  • Connect (Connector Server)

  • Connect (Server Cluster)

AM Configuration
Feature Dynamic
(devops)
ForgeRock SREs
(promotion)

Applications > Agents

  • IG Agent

  • Java Policy Agents

  • Web Policy Agents

Applications > Federation

  • Circle of Trust

  • SAML2 Entity Provider

Applications > OAuth 2.0 (excluding scripts)

  • Clients

  • Remote Consent

  • Software Publisher

  • Trusted JWT Issuer

Password policy (created from Identity Cloud UI)

Authentication trees

Authorization

  • Policy sets

  • Resource types

Scripts (all)

Services (per realm)

  • OAuth 2.0 provider

  • Social IdP services

  • Policy configuration

  • Base URL source

IDM Configuration
Feature Dynamic
(devops)
Static
(promotion)

Managed objects

Connector configurations

Sync mappings

Roles & assignments

Email notifications

How do we determine what is static and dynamic configuration?

ForgeRock considers all configuration static, except for the two types of config data that may be changed at runtime: applications and access policies. These config data types can be created on the fly, and can be used immediately afterwards.

Applications represented by OAuth2 clients can be registered at runtime through the Dynamic Client Registration Protocol. Access policies are created every time an end user shares access to a resource.

ForgeRock recognizes that other types of applications or access policies might not change at runtime. But ForgeRock products handle each data class consistently, so we can leverage potential usage patterns in the future.

What exactly is promoted and what is not?

These artifacts are NOT promoted. They remain unchanged during the promotion process:

  • Identities:
    Users, things, admins, roles, and assignments

  • Applications:
    Federations, OAuth2 clients (using the Applications Admin UI), Gateways and Agents

  • Access policies:
    AM policy sets and resource types

All other configuration is promoted between environments.

How do I manage configuration?

You have the choice of using the Identity Cloud Admin UI, or using the REST APIs for configuration.

Static configuration
  • You make changes in your development environment.

  • ForgeRock SREs promote it to staging or production when you are ready.

Dynamic configuration
  • You configure applications and add users in your development, staging and production environments.

  • Changes take effect immediately.

What if I need to roll back a configuration?

ForgeRock can roll back static configuration for you. Configuration data is maintained in Git repositories within your environment. So, configuration data can be restored as a whole to previous settings.

When you request a rollback, ForgeRock reverts your development environment to the point in time you specify. ForgeRock can then promote that configuration to staging and production environments when confirmed by you.

Dynamic configuration is not altered when rolling back in this way. Users, applications, and access policies remain as they are.

Follow the instructions to promote configuration changes. In the Request Type dialog box, choose Restore from backup.

How do I ask ForgeRock to move configuration for me?

Follow the instructions in the section To promote configuration changes.

ForgeRock promotes one step at a time. We’ll ask you to check and confirm the staging environment status before we promote the configuration to the production environment.

How long does the promotion process take?

Promotion normally takes 2 hours, and is carried out by the end of the next business day. Promotions occur during GMT business hours, and US Central time business hours Monday-Friday excluding ForgeRock holidays. ForgeRock prevents changes to the development environment while promotion is in progress.

What if some configuration attributes must vary per environment?

We understand that sometimes you have to use a configuration attribute value that is not identical across development, staging, and production environments. For example, you might need one set of credentials for an external service in the development environment, but a different set of credentials in the production environment.

See Environment Secrets and Variables (ESVs) for an explanation of how this type of configuration is handled, then follow the process in To promote configuration changes.

Can I promote the configuration for an individual Alpha or Bravo realm?

ForgeRock promotes configuration at the environment level, so promotions always include both realms. It is therefore not possible to promote the configuration for an individual Alpha or Bravo realm between environments.

Monitor Your Tenant

Identity Cloud lets you monitor uptime status and system performance.

Monitor uptime status

Tenant status page

You can monitor uptime and historical trends for your staging and production tenant environments using your tenant status page.

  1. In a browser, go to https://forgerock.statuspage.io/.

  2. On the sign-in page, enter the credentials you received when you registered with Identity Cloud.
    If you don’t have access to this page, submit a support ticket: Go to Backstage, and click Support.

  3. Click Authenticate.

Services monitored in the status page include:

  • Access Management

  • Identity Management

  • End User UI

  • Login UI

  • Admin UI

  • Logs

400

Add more tenant administrators to the tenant status page

If monitoring Identity Cloud uptime status is part of a particular tenant administrator’s role, submit a support request to give the individual access to the tenant status page.

  • To submit a support request, go to Backstage, and click Support.

  • You can request access on behalf of one or more tenant administrators, including yourself.

  • In the request, provide the email address of each tenant administrator you want to have status page access.

You can view real-time status of your staging and production environments, and a listing of service incidents.

400

For more details, click View historical uptime. Then click Filter Components to view reports on incidents in selected Identity Cloud components.

400

Identity Cloud also provides APIs for extracting log data. For more information, see View Audit Logs.

Monitor system performance

Identity Cloud provides monitoring endpoints you can use with Prometheus.

Endpoint Purpose

/monitoring/prometheus/am

Produces Prometheus-formatted metrics for Access Management

/monitoring/prometheus/idm

Produces Prometheus-formatted metrics for Identity Management

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:

  1. Download and extract the ForgeRock Identity Cloud Monitoring Demo ZIP file.

  2. Edit the setup_monitoring_config.sh file:

    1. In the TENANT_DOMAIN variable, enter the domain name of your tenant.

      Do not include the protocol, and do not add a trailing slash.

      For example:

      TENANT_DOMAIN="mytenant-01.forgeblocks.com"
    2. In the API_KEY_ID and API_KEY_SECRET variables, enter the API credentials you obtained earlier.

      For example:

      API_KEY_ID="b977d5724ef...562e4c57"
      API_KEY_SECRET="d3628be865ce152f49...870e5fd3506c4"
    3. Save your changes.

  3. Run the setup_monitoring_config.sh script.

    The Shell script will set up the following config files:

    Config File Description

    prometheus/prometheus.yml

    The script populates the tenant domain and API credentials.

    docker/docker-compose.yml

    The script populates the working directory path.

  4. Run the following Docker command:

    docker-compose -f docker/docker-compose.yml up

    The command downloads a Prometheus Docker image and configures it for your tenant. It also downloads a Grafana Docker image, and configures it to use the Prometheus image as a data source.

  5. When the command output for the "grafana_1" container displays a message that contains "HTTP Server Listen", open http://localhost:3000 in a web browser.

  6. Log in with username "admin", password "admin".

  7. Enter a new password to use for the administrator, or click Skip.

  8. On the Grafana Home page, select Dashboards, and then select Manage.

  9. On the Dashboards page, select AM Overview.

    The AM Overview dashboard opens:

    Sample AM Grafana Dashboard

    View the Prometheus dashboard at http://localhost:9090.

View Audit and Debug Logs

Overview

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

  • Use audit logs to investigate user and system behavior.

  • Use debug logs to investigate any issues which may arise in production.

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

You need to get an API key and secret before you can authenticate to the endpoints.

Sources

Identity Cloud stores logs in various sources, to make browsing them simpler.

The following knowledge base article lists the sources available, and describes their purpose: https://backstage.forgerock.com/knowledge/kb/article/a37739488.

Get sources

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

Example request:

curl \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
'https://<tenant-name>.forgeblocks.com/monitoring/logs/sources'

Example response:

{
    "result": [
        "<string>",
        "<string>"
    ],
    "resultCount": "<integer>",
    "pagedResultsCookie": "<string>",
    "totalPagedResultsPolicy": "<string>",
    "totalPagedResults": "<integer>",
    "remainingPagedResults": "<integer>"
}

Identity Cloud returns the available sources in the result array.

View logs

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

Example request:

curl  --get \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=am-activity' \
'https://<tenant-name>.forgeblocks.com/monitoring/logs'

Example response:

{
    "result": [
        {
            "payload": "<object>",
            "timestamp": "<dateTime>",
            "type": "<string>"
        },
        {
            "payload": "<object>",
            "timestamp": "<dateTime>",
            "type": "<string>"
        }
    ],
    "resultCount": "<integer>",
    "pagedResultsCookie": "<string>",
    "totalPagedResultsPolicy": "<string>",
    "totalPagedResults": "<integer>",
    "remainingPagedResults": "<integer>"
}

Identity Cloud returns the available logs in the result array.

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

Use the beginTime and endTime query parameters to return records created between the two times.

Specify UTC times, in ISO 8601 format.

For example:

curl --get \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=am-activity' \
--data 'beginTime=2020-09-11T09:00:31Z' \
--data 'endTime=2020-09-18T17:30:59Z' \
'https://<tenant-name>.forgeblocks.com/monitoring/logs'

Tail logs

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

The first call to the tail endpoint returns results from the last 15 seconds. Subsequent calls (when using _pagedResultsToken for example) return logs from:

  • Time of last line from previous call to tail

  • Log timestamp

  • Now

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:

curl --get \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=am-activity' \
'https://<tenant-name>.forgeblocks.com/monitoring/logs/tail'

Example response:

{
    "result": [
        {
            "payload": "<object>",
            "timestamp": "<dateTime>",
            "type": "<string>"
        },
        {
            "payload": "<object>",
            "timestamp": "<dateTime>",
            "type": "<string>"
        }
    ],
    "resultCount": "<integer>",
    "pagedResultsCookie": "<string>",
    "totalPagedResultsPolicy": "<string>",
    "totalPagedResults": "<integer>",
    "remainingPagedResults": "<integer>"
}

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

curl --get \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=am-access,idm-access,idm-sync,idm-activity' \
'https://<tenant-name>.forgeblocks.com/monitoring/logs/tail'

To keep tailing, take the pagedResultsCookie field and pass it back to the tail endpoint. This retrieves all records stored since that request.

Example request:

curl --get \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=am-access,idm-access,idm-sync,idm-activity&_pagedResultsCookie=<pagedResultsCookie>'
'https://<tenant-name>.forgeblocks.com/monitoring/logs/tail'

Filter logs using a transaction ID

All log events for an external request into Identity Cloud are assigned the same UUID transaction ID. An example of a transaction ID is 918ddc87-791a-480b-acf7-7982b7bea973-16108.

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

curl --get \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=userstore-access&transactionId=<transaction-id>' (1)
'https://<tenant-name>.forgeblocks.com/monitoring/logs'
1 Replace <transaction-id> with a transaction ID

Add additional fields to audit requests

The following knowledge base article describes how to add additional fields to an audit request: https://backstage.forgerock.com/knowledge/kb/article/a94880145.

Rate limiting

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.

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

X-Rate-Limit-Limit

The maximum number of requests allowed in the current rate limit window.

X-Rate-Limit-Remaining

The number of requests remaining in the current rate limit window.

X-Rate-Limit-Reset

The time at which the rate limit window is reset, specified in UTC epoch time.

Email Provider

Overview

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.

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

The email provider is configured at the tenant level. This means that configuration changes made in one realm are applied to both realms.

Setup process

  1. Customize an email template.

  2. In your tenant development environment, create and test a journey that uses an email node. By default, the email provider uses the built-in SMTP server to test the email node.

  3. When you’re satisfied with your test results:

    1. Configure the email provider to use your own external SMTP server.

    2. Verify that your email templates work with the external SMTP server.

  4. Promote your configuration changes to your tenant staging environment.

  5. (Optional) You can revert the email provider to use the built-in SMTP server for testing purposes. But, be sure to reconfigure the email provider to use your own external SMTP server before promoting configuration changes to your tenant staging environment.

Do not use the email provider with the built-in SMTP server in a tenant production environment. Identity Cloud provides this ready-to-use server for testing purposes only.

Configure the email provider to use an external SMTP server

The email provider is configured at the tenant level. This means that configuration changes made in one realm are applied to both realms.

When you’re ready to go to production, complete these steps to configure the email provider to use your own external SMTP server:

  1. In the Identity Cloud Admin UI, go to Email > Provider.

  2. On the Email Provider page, enable the option Use my own email provider.

  3. Enter the following details:

    From

    Email address of the organization or individual sending the email.

    Example: mycompany@example.com.

    Not set by default, but required.

    Host

    Host name or IP address of your SMTP server.

    When no host name is specified, Identity Cloud uses the built-in SMTP server.

    Port

    Port number of your SMTP server.

    Many SMTP servers require the use of a secure port such as 465 or 587. Many ISPs flag email from port 25 as spam.

    Default value is 587.

    Username

    Username for your SMTP server account.

    Password

    Password for your SMTP server account.

    Advanced settings

    Socket Connection Timeout (ms)

    Elapsed time before the Identity Cloud server times out due to unsuccessful socket connection. A setting of 0 disables this timeout.

    Default is 300000 ms (5 minutes).

    Socket Write Timeout (ms)

    Elapsed time before the Identity Cloud server times out because client can’t write to the SMTP server. A setting of 0 disables this timeout.

    Default is 300000 (5 minutes).

    Socket Timeout (ms)

    Elapsed time before the Identity Cloud server times out due to inactivity. A setting of 0 disables this timeout.

    Default is 300000 (5 minutes).

    Use STARTTLS

    • If enabled, and if the SMTP server supports the STARTTLS command, then the Identity Cloud server switches to a TLS-protected connection before issuing any login commands.

    • If the SMTP server does not support STARTTLS, the connection continues without the use of TLS.

    Disabled by default.

    Use SSL

    If enabled, the Identity Cloud server uses SSL.

    Disabled by default.

  4. To test your configuration, click Send Test Email.

    1. In the Send Test Email dialog box, enter your own email address.

    2. Click Send.

      If the test is successful, you’ll see a test email in your email inbox.

  5. To save the email provider configuration, click Save.

Revert the email provider to use the built-in SMTP server

The email provider is configured at the tenant level. This means that configuration changes made in one realm are applied to both realms.

If you need to revert the email provider to use the built-in SMTP server, you can leave the Use my own email provider option enabled and configure the email provider with some default settings:

  1. In the Identity Cloud Admin UI, go to Email > Provider.

  2. On the Email Provider page, leave the option Use my own email provider enabled.

  3. Enter the following details:

    From

    info@example.com

    Host

    smtp.example.com

    Port

    587

    Username

    user@example.com

    Password

  4. To test your configuration, click Send Test Email.

    1. In the Send Test Email dialog box, enter your own email address.

    2. Click Send.

      If the test is successful, you’ll see a test email in your email inbox.

  5. To save the email provider configuration, click Save.

Using Email Templates

Overview

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.

Here’s sample body text that is included with the default templates:

Forgotten Username

[Barbara Jensen], your username is [bjensen].
If you received this email in error, please disregard.
Click [link] to sign in.

Registration

This is your registration email. Email verification [link]

Reset Password

Click to reset your password. Password reset [link]

Update Password

Verify email to update password. Update password [link]

Welcome

Welcome to Identity Cloud. Your username is [bjensen].

Customize an email template

  1. In the Identity Cloud Admin UI, go to Email > Templates.

  2. Click a template name.

  3. In the template page, click Edit.

  4. On the Edit Template page enter the following details:

    • Template Name: Display name for the template.

    • From Address: Enter an email address for the group or individual sending the email.

    • From Name: Enter a name for the group or individual sending the email.

    • Message: Enter the email subject line text.

      • Locale: Select the area of the world where email will be received. This determines the language to use in the email. Click Add a locale if the one you want is not on the list.

      • Subject: Enter a phrase to display in the email subject line.

    • Markdown: Edit the text in the body of the email.

      • Use Markdown to edit the text.

      • Click the available variables link to choose from the Available Properties list.

    • Style: Change the text formatting.
      Use HTML or hexadecimal color codes to change the default colors for any of the following:

      • Email background color

      • Heading text color

      • Button background color

      • Body text background color

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

Create a new email template

  1. In the Identity Cloud Admin UI, go to Email > Templates.

  2. Click + New Template.

  3. In the New Template dialog box, provide the following details:

    • Template ID: Enter a template identifier.
      Use only lowercase letters and numerals. No spaces or special characters allowed.

    • (Optional) Display Name: This name will be displayed in the Email Templates list.

  4. Click Save.

  5. Customize your new email template.

Manage email templates

In the Identity Cloud Admin UI, go to Email > Templates.

  • Click + New Template to create a new email template.

  • Select a template name, and click its More () menu:

    • Click Preview to view the contents of the selected template and send a test email.

      • On the preview page, to send a test email, click Send Test Email.

      • On the preview page, to edit or customize the email template, click Edit.
        See Customize an email template.

    • Click Edit to change the wording or colors in the selected template.
      See Customize an email template.

    • Click Deactivate to temporarily disable the selected template.

    • Click Delete to permanently remove the selected template from your tenant.

      Deleting an email template cannot be undone.

Configure CORS

Overview

Cross-origin resource sharing (CORS) lets user agents make cross-domain server requests. For example, CORS lets your web application make requests to other websites from the browser.

By default, a CORS service is configured between Identity Cloud the the ForgeRock SDKs. You can add additional CORS configurations, for example, for your own APIs or SDK.

Configure CORS by using the AM REST APIs. Or, you can use the Identity Cloud Admin UI described in the following sections.

cors config

View CORS configurations

  1. Open the Tenant settings menu, and choose Tenant settings.

  2. On the Tenant Settings page, click Global Settings > Cross-Origin Resource Sharing (CORS).

Add a new CORS configuration

  1. Open the Tenant settings menu, and choose Tenant settings.

  2. On the Tenant Settings page, click Global Settings > Cross-Origin Resource Sharing (CORS).

  3. Click + New CORS Configuration.

  4. On the New CORS Configuration dialog box, choose a configuration type.

    Configuration types:

    ForgeRock SDK

    Choose this option when you want to work with the ForgeRock SDK.
    Identity Cloud pre-configures accepted origins, methods, and headers for you. You can modify the configuration in the next step.

    Custom

    Choose this option when you want to use your own SDK, APIs, or other software components.

  5. Click Next.

  6. In the New CORS Configuration dialog box, provide CORS details.

    CORS details:

    Name

    Default is ForgeRock SDK.
    Enter a display name. Use only numerals, letters, and hyphens (-).

    Accepted Origin

    Required. Accepted origins that will be allowed to make requests to ForgeRock from your application in a cross-origin context. Wildcards are not supported. Each value should be identical to the origin of the CORS request.
    Example: ` https://myapp.example.com:443`

    Accepted Methods

    Defaults are POST and GET. The set of (non-simple) accepted HTTP methods allowed when making CORS requests to ForgeRock. Use only uppercase characters.

    Accepted Headers (optional)

    Accepted header names when making requests from the above specified trusted domains.
    Header names are case-insensitive. By default, the following simple headers are explicitly accepted: Cache-Control, Content-Language, ExpiresLast-Modified, Pragma.
    If you don’t specify values for this element, then the presence of any header in the CORS request, other than the simple headers listed above, will cause the request to be rejected.

    Advanced settings:

    Exposed Headers (optional)

    Add the response header names that ForgeRock returns.
    The header names are case-insensitive. User agents can make use of any headers that are listed in this property, as well as these simple response headers: Cache-Control, Content-Language, Expires, Last-Modified, Pragma, and Content-Type. User agents must filter out all other response headers.

    Enable Caching

    Max age is the maximum length of time, in seconds, that the browser is allowed to cache the pre-flight response. The value is included in pre-flight responses, in the Access-Control-Max-Age header.

    Allow Credentials

    Enable this property if you send Authorization headers as part of the CORS requests, or need to include information in cookies when making requests.

    When enabled, AM sets the Access-Control-Allow-Credentials: true header.

  7. Click Save CORS Configuration.

Activate or Deactivate CORS Configuration

  • To activate or deactivate all CORS configurations:

    1. Open the Tenant settings menu, and choose Tenant settings.

    2. On the Tenant Settings page, click Global Settings > Cross-Origin Resource Sharing (CORS).

    3. On the CORS Configurations page, in the upper right side, click Activate or Deactivate.

  • To deactivate an individual CORS configuartion:

    1. Open the Tenant settings menu, and choose Tenant settings.

    2. On the Tenant Settings page, click Global Settings > Cross-Origin Resource Sharing (CORS).

    3. On the CORS Configurations page, find the name of the configuration you want to edit.

    4. Click its More () menu, and choose Edit > Deactivate.

Edit a CORS configuration

  1. Open the Tenant settings menu, and choose Tenant settings.

  2. On the Tenant Settings page, click Global Settings > Cross-Origin Resource Sharing (CORS).

  3. On the CORS Configurations page, find the name of the configuation you want to edit.

  4. Click its More () menu, and choose Edit.

  5. From the Edit menu:

    • Edit opens an edit window. See Add a new CORS configuration for edit details.

    • Deactivate deactivates only this configuration.

    • Delete removes this configuration. This cannot be undone.

More Information

Realm Settings

Overview

Realms let you to 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 with 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.

Manage realm settings

  1. In the Identity Cloud Admin UI (upper left), open the Realm menu.

    150

  2. Go to Realm Settings > Details.

  3. On the Details page:

    • The Status bar indicates whether the realm is Active or Inactive.

    • To take the realm out of service, click Deactivate.
      When a realm is deactivated, users and devices contained in the realm will not be able to access its applications. Identity and app information is still registered to your identity platform.

    • Name: The realm name is non-configurable.

    • (Optional) DNS Aliases: Alternative display names for this the realm URL.

    • Use Client-based Sessions: Enable this option to enable signing and encryption of the JWT in the global session service.

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

Override realm authentication attributes

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

  1. In the Identity Cloud Admin UI, click Native Consoles > Access Management.

  2. In the AM Admin UI, go to> Authentication > Settings.

core auth attributes

For detailed property information, see Core Authentication Attributes.

Delete a realm

  1. In the Identity Cloud Admin UI, open the Realm menu (upper left).
    150

  2. Go to Realm Setting > Details.

  3. On the Realm Details page, click Delete Realm.

Once you delete a realm, the realm cannot be restored.

Switch realms

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

  1. In the Identity Cloud Admin UI, open the Realm menu (upper left).
    150

  2. Click Switch realm.

  3. In the Switch Realm dialog box, click Switch.

Alpha and Bravo Realms

Overview

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.

Identity Cloud currently does not support more than two realms in the same tenant.

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

idcloudui identities manage alpha bravo

End-user sign-in

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

  • Alpha realm members use https://<tenant-name>.forgeblocks.com/login/?realm=alpha/#/

  • Bravo realm members use https://<tenant-name>.forgeblocks.com/login/?realm=bravo/#/

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

Delegated administration

The Bravo Realm does not support delegated administration.

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.

You can assign the internal roles in two different ways using the Identity Cloud Admin UI:

  • To add an internal role to a user, go to Identities > Manage > Realm - Users.Select a user, then select the Authorization Roles tab, then click the Add Authorization Roles button:

    idcloudui identities user authorization roles tab

  • To add a user to an internal role, go to Identities > Manage > Internal Roles.Select a role, then select the Members tab, then click the Add Members button:

    idcloudui identities internal role members tab

However, in the Bravo realm, while you can also set up internal roles for delegated administration, you cannot use them.You cannot add a user to an internal role, and even though it appears possible to add an internal role to a user, this will not correctly link the user to the role.If you attempt this, the user will not be listed in the internal role Members tab.

The following table summarizes these differences:

Action Alpha Realm Bravo Realm

Create internal role for the purposes of delegated administration

Add user to internal role

Add internal role to user

⚠️ ️
appears possible but will not work

Custom Domains

Overview

Configure a custom domain name when you want to use a customer-friendly URL to access Identity Cloud. You can use your own company name or brand, for example, in place of the default forgerock.io domain.

When choosing a custom domain name, consider the following:

  • You can set a custom domain name only at the realm level.

  • You can set multiple custom domain names per realm.

  • The Identity Cloud Admin UI will continue to display the URL
    https://<tenant-name>.id.forgerock.io.

  • Don’t use your top-level domain name.

    • Wrong: mycompany.com

    • Right: id.mycompany.com

  • Changing your custom domain name affects your end-user UIs and REST APIs.

Set up a custom domain in Identity Cloud

Configure a custom domain

Before you begin, open a new browser window and sign in to the website for your domain name provider. For these steps, keep Identity Cloud open in a separate browser window.

  1. In the Identity Cloud Admin UI, go to Realm > Realm Settings > Custom Domain.

  2. Click + Add a Custom Domain.

  3. In the Add a Custom Domain dialog box, enter the domain name you want to use, then click Verify.
    The domain name must be unique, and must contain at least one period (dot).
    Example: id.mycompany.com.

    After Identity Cloud validates your domain name, you’re prompted to verify your domain name ownership. In the Verify Domain Name Ownership dialog box, Identity Cloud provides Host and Data information you’ll need to prove that you own the domain you’ve named.

  4. Create or modify your CNAME record.

    1. In a separate browser window, sign in to the website for your domain name registrar.

    2. Find the CNAME record for your domain.
      If you don’t already have a CNAME record for your domain, then follow the domain name provider’s instructions to create one now.

    3. In the CNAME record for your domain, copy and paste the Host and Data values provided in the Verify the Domain Ownership dialog box.

    4. Follow the domain name provider’s instructions to complete the operation.
      It may take up to 48 hours for the domain name changes to propagate.

  5. Return to the Verify the Domain Ownership dialog box. Click Verify.

  6. Configure the Base URL Source.

    1. Go to Native Access Consoles > Access Management.

    2. From the Realms menu, choose the realm that contains the custom domain name.

    3. On the Services page, click Base URL Source to edit its configuration.

    4. On the Base URL Source page, change the Base URL Source option to
      "Host/protocol from incoming request".

    5. Click Save Changes.

      After you’ve successfully configured your custom domain:

      • Identity Cloud generates the SSL certificates your domain needs.

      • The custom domain name is added to the Realm Settings.

      • The FDQN for your custom domain name is mapped to server defaults.

      • The custom domain name is added to UI endUserUIClient redirect URIs.

      • Both tenant domain and custom domain URL paths will work. However, this does not apply to the OIDC configuration discovery endpoint.

        Examples:
        • For AM endpoint:
           https://<tenant-name>.id.forgerock.io/am/json/realms/root/realms/alpha/authenticate
           you can use:
           https://id.mycompany.com/am/json/realms/root/realms/alpha/authenticate

        • For IDM endpoint:
           https://<tenant-name>.id.forgerock.io/openidm/managed/alpha_user/<uuid>
           you can use:
           https://id.mycompany.com/openidm/managed/alpha_user/<uuid>

Verify a custom domain

  • It may take up to 48 hours for the domain name changes to propagate. If you try to use the new domain name to access your website, error messages may display until the changes take effect.

  • To confirm that Identity Cloud is serving traffic over HTTPS (TLS) for your custom domain name, in a browser, go to your custom domain location. Example: https://id.mycompany.com.

  • To test the hosted pages, use an incognito or private browser window to access an end-user URL. Example:
    https://id.mycompany.com/login/?authIndexType=service&authIndexValue=mytreename#/

  • If error messages still display after 48 hours, make sure your Identity Cloud domain name settings are correct and match your CNAME record.

Promote custom domain placeholders

To prepare your Identity Cloud tenant to use a custom domain, ForgeRock engineers update your tenant configuration with placeholders that reference the custom domain. For the custom domain to work correctly in your staging or production environments, these configuration placeholders need to be promoted from your development environment.

See Promote Configuration for more information on the promotion process.

Verify a custom domain in Google

If you use Google as a social login IDP, you will need to use your domain to configure the redirect URL fields of your OAuth 2.0 apps. This might create prompts from Google to verify your domain with your domain provider. This can be done through the Google Search Console. See https://support.google.com/webmasters/answer/9008080?hl=en.

Access OIDC configuration discovery endpoint

If you configure a custom domain, the OIDC configuration discovery endpoint URL changes:

Domain context Endpoint URL

Default ForgeRock domain

  • https://<tenant-name>.forgeblocks.com/am/oauth2/realms/root/realms/<realm>/.well-known/openid-configuration

Custom domain

  • Wrong:
    https://<custom-domain>/am/oauth2/realms/root/realms/<realm>/.well-known/openid-configuration

  • Right:
    https://<custom-domain>/.well-known/openid-configuration

Using the wrong endpoint URL can result in an OIDC discovery failure due to an issuer mismatch.

Applications

Overview

Your applications act as clients to Identity Cloud.

ForgeRock uses both OAuth 2.0 and OpenID Connect protocols to protect your applications. When you register a supported application or service, Identity Cloud sets the OAuth 2.0 grant type based on the type of application you’re registering. Identity Cloud also sets OpenID Connect default options for you. You can customize configuration in the application’s client profile.

To get started, first register your application or service to your tenant. Then, create a client profile for the application or service.

You can view and manage all your applications in the Applications page of the Identity Cloud Admin UI.

The Identity Cloud Admin UI only supports a maximum of 500 applications.

See the quick takes on this page:

Register an application or service

  1. In the Identity Cloud Admin UI, go to Applications, and click + New Application.

  2. In the New Consumer App dialog box, choose the application type you want to register:

  3. In the Web Application Credentials dialog box, enter a Client ID to be displayed in the Applications list, and if shown, enter a Client Secret.

  4. Click Create Application.

Create a client profile

  1. In the Identity Cloud Admin UI, click Applications.

  2. In the Applications list, find the application name, then click More (), and choose Edit.

  3. Review read-only Client Credentials:

    Client Credentials

    Discovery URI

    AM URL base for OpenID Provider Configuration.
    Default: http://openam.example.com:8088/openam/oauth2

    Client ID

    Identifier used to register your client with AM’s authorization server, and then used when your client must authenticate to AM.

    Client Secret

    Password used to register your client with AM’s authorization server, and then used when your client must authenticate to AM.

  4. Edit General Settings:

    General Settings

    Name

    Specify a client name to display to the resource owner when the resource owner is asked to authorize client access to protected resources.

    App Logo URI

    Specify the location of your custom logo image file.

    Description

    Specify a client description to display to the resource owner when the resource owner is asked to authorize client access to protected resources.

    Sign-in URLs

    Custom URL for handling login. Overrides the default OpenAM login page.

    Sign-out URLs

    Custom URL for handling logout. Example: http://client.example.com:8080/openam/XUI/?realm=/#logout.

    Grant Types

    Specify the set of OAuth 2.0 grant types, also known as grant flows, allowed for this client:

    Authorization Code

    (default) Instead of requesting authorization directly from the user, your client application or service directs the user to an authorization server (Identity Cloud).

    Back Channel Request

     

    Implicit

    The client is issued an access token directly. No intermediate credentials (such as an authorization code) are issued. This grant type can potentially pose a security risk. See the "Implicit Grant" section in the ForgeRock AM 7 OAuth 2.0 Guide.

    Resource Owner Password Credentials

    Username and password can be used directly as an authorization grant to obtain an access token. The credentials should only be used when there is a high degree of trust between the user and the client application or service.

    Client Credentials

    Used when the client is acting on its own behalf or requests access to protected resources based previously-arranged authorization.

    Refresh Token

    Credentials used to obtain access tokens.

    Device Code

    Authorizes a client device, such as smarthome thermostat, to access its service on an end user’s behalf. For example, the end user could log in to the thermostat service using a cell phone to enter a code displayed on the thermostat.

    SAML2

    Leverages the REST-based services provided by AM’s OAuth 2.0 support. Maintains existing SAML v2.0 federation implementation.

    Scopes

    Specify scopes that are to be presented to the resource owner when the resource owner is asked to authorize client access to protected resources.

    The openid scope is required.

  5. Edit Advanced Settings:

    Access

    Add Default Scopes

    Scopes to be set automatically when tokens are issued. The openid scope is required.

    Add Response types

    Specify the response types that the client uses. The response type value specifies the flow that determine how the ID token and access token are returned to the client. By default, the following response types are available:

    • code. Specifies that the client application requests an authorization code grant.

    • token. Specifies that the client application requests an implicit grant type and requests a token from the API.

    • id_token. Specifies that the client application requests an ID token.

    • code token. Specifies that the client application requests an access token, access token type, and an authorization code.

    • token id_token. Specifies that the client application requests an access token, access token type, and an ID token.

    • code id_token. Specifies that the client application requests an authorization code and an ID token.

    • code token id_token. Specifies that the client application requests an authorization code, access token, access token type, and an ID token.

    Add Claims

    Claims can be in entered as simple strings, such as name, email, profile, or sub. Or, as a pipe-separated string in the format: scope|locale|localized description. For example, name|en|Full name of user.

    Allow wildcard ports in redirect URLs

    Specify whether AM allows the use of wildcards (* characters) in the redirection URI port to match one or more ports.

    The URL configured in the redirection URI must be either localhost, 127.0.01, or ::1. For example, http://localhost:*/, https://127.0.0.1:80*/, or https://[::1]:*443/.

    Enable this setting, for example, for desktop applications that start a web server on a random free port during the OAuth 2.0 flow.

    Authentication

    Token Endpoint
    Authentication Method

    Authentication method client uses to authenticate to AM.
    Choose one:

    • client_secret_basic. Clients authenticate using the HTTP Basic authentication scheme after receiving a client_secret value.

    • client_secret_post. Clients authenticate by including the client credentials in the request body after receiving a client_secret value.

    • private_key_jwt. Clients sign a JSON web token (JWT) with a registered public key.

    Token Endpoint Authentication Method (Client Type)

    • Confidential clients can maintain the confidentiality of their credentials. For example, a web application runs on a server where its credentials are protected.

    • Public clients run the risk of exposing their passwords to a host or user agent. For example, a JavaScript client running in a browser may be accessible to the public at large.

    Implied Consent

    When enabled, the resource owner will not be asked for consent during authorization flows. The OAuth2 Provider must also be configured to allow clients to skip consent.

    OAuth 2.0 Mix-Up Mitigation active

    Enable this setting only if this OAuth 2.0 client supports the OAuth 2.0 Mix-Up Mitigation draft, otherwise AM will fail to validate access token requests received from this client.

    Add Default ACR values

    Default Authentication Context Class Reference values. Specify strings that will be requested as Voluntary Claims by default in all incoming requests.

    Add Request URIs

    Specify request_uri values that a dynamic client would pre-register.

    Client JWT Bearer
    Public Key

    A base64-encoded X509 certificate in PEM format used to obtain the client’s JWT bearer public key. The client uses the private key to sign client authentication and access token request JWTs, while AM uses the public key for verification.

    Subject Type

    Default value is public.

    • Choose pairwise if you want each client to receive a different subject value. This prevents correlation between clients.

    • Choose public if you want each client to receive the same subject value.

    Default Max Age

    Enable this option to enforce a default maximum age of 10 minutes. If the user session is not currently active, and if more than ten minutes have passed since the user last authenticated, then the user must be authenticated again.

    Use Certificate-Bound Access Tokens

    Enable this option if you want access tokens issued to this client to be bound to an X.509 certificate. When enabled, access tokens will use the X.509 certificate to authenticate to the access_token endpoint.

    Token Lifetimes

    Authorization code lifetime (seconds)

    The time an authorization code is valid for.
    Default value: 120

    Access token lifetime (seconds)

    The time an access token is valid for, in seconds
    If you set the value to 0, the access token will not be valid. A maximum lifetime of 600 seconds is recommended. Default value: 3600

    Refresh token lifetime (seconds)

    The time a refresh token is valid for.
    If this field is set to -1, the refresh token will never expire. Default value: 604800

    JWT token lifetime (seconds)

    The amount of time the JWT is valid for. Default value: 3600

    Consent Screen

    Add Display Name

    Custom user-facing title. In this example, MyClient.

    Add Display Description

    User-facing instruction text. In this example, "This application is requesting the following information:"

    Add Privacy Policy URI

    URI containing the client’s privacy policy documentation. The URI is displayed as a link in the consent page.

    200

    Client Management

    Access Token

    Specify the registration_access_token value that you provide when registering the client, and then subsequently, when reading or updating the client profile.

    Session Management

    Client Session URI

    Specify the relying party (client) URI to which the OpenID Connect Provider sends "session changed" notification. Message is sent using the HTML 5 postMessage API.

    Endpoint Response Formats

    User info response format

    Specify the output format from the userinfo endpoint.
    The supported output formats are:

    • (default) User info JSON response format.

    • User info encrypted JWT response format.

    • User info signed JWT response format.

    • ︎ User info signed then encrypted response format.

    Token introspection response format

    Specifies the format of the token introspection response. The possible values for this property are:

    • JSON response format

    • Signed JWT response format

    • Signed then encrypted JWT response format

    Signing and Encryption

    Public key selector

    Select the public key for this client, which comes from the JWKs_URI, manual JWKs, or X.509 field.

    JSON Web Key URI

    The URI that contains the client public keys in JSON web key format.

    JSON Web Key

    Raw JSON web key value containing the client public keys.

    Client ID Token Public Encryption Key

    Base64-encoded public key for encrypting ID tokens.

    Enable ID Token Encryption

    When enabled, encryption uses the algorithm that the ID token must be encrypted with. Default algorithm value is RSA1_5 (RSAES-PKCS1-V1_5).

  6. Click Save.

Supported application types

When you register an application or service, Identity Cloud automatically sets the optimal configuration for you. To change the default settings, edit the client profile.

Native / SPA applications with PKCE

Native applications are developed for specific platforms or devices. Examples include the applications you see on mobile phones, and applications dedicated to the MacOS platform.

Single-page applications (SPAs) are OAuth 2.0 clients that run in a user’s web browser. SPAs use PKCE to verify the client because SPAs do not have a way to secure the client_secret value. PKCE stands for Proof Key Code Exchange, a security standard explained in the IETF specification Proof Key for Code Exchange by OAuth Public Clients.

For a deep dive on how ForgeRock implements PKCE for native and SPA applications, see Authorization Code Grant With PKCE.

Web applications

Web applications are OAuth 2.0 clients that run on a web server. End users (resource owners) access web applications using a web browser. The application makes API calls using a server-side programming language. The end user has no access to the OAuth 2.0 client secret, or any access tokens issued by the authorization server.

Service / Machine-to-machine applications

Machine-to-machine (M2M) applications interact with an API, and no user involvement is necessary. The application acts on behalf of itself, and not on behalf of a user. The application can ask for an access token directly without involving a user in the process at all. A smart meter that tracks your utility usage, and wearable devices that gather and communicate health data use services and M2M applications.

OAuth 2.0 and OpenID Connect

Identity Cloud uses OAuth 2.0 and OpenID Connect to protect your applications.

OAuth 2.0

Identity Cloud provides an authorization service in the OAuth 2.0 authorization flow. OAuth 2.0 lets you set up access to your resources without sharing end-user account information. For a deep dive, see RFC6749.

You may encounter domain validation prompts when using forgeblocks.com and id.forgerock.io domains as redirect URLs in your Google OAuth 2.0 applications. To resolve this, you must use a custom domain, and then set up domain verification with Google.

You may encounter "No provider found" errors when using forgeblocks.com and id.forgerock.io domains as redirect URLs in your OAuth 2.0 applications. To resolve this, either modify the redirect URL to include a realm identifier, or use a custom domain:

  • Wrong:
    https://<tenant-name>.forgeblocks.com/am/oauth2/client/form_post/…​

  • Right:
    https://<tenant-name>.forgeblocks.com/am/oauth2/<realm>/client/form_post/…​
    or
    https://<custom-domain>/am/oauth2/client/form_post/…​

A custom domain acts as a realm DNS alias, so when it is used as a redirect URL, Identity Cloud implicitly knows which realm to use.

OpenID Connect

OpenID Connect (OIDC) provides an identity layer on top of OAuth 2.0. OIDC lets a client make assertions about the user’s identity, and their means of authentication. For a deep dive, see the ForgeRock Access Management OpenID Connect 1.0 Guide.

What’s in the client profile

Changing the client profile settings requires a working knowledge of the OAuth 2.0, its grant types, and its components. If no one has given you direction on how to configure the client profile, you’ll want to read up on some basic concepts.

Here are some links to deep dives in the ForgeRock OAuth 2.0 Guide:

Scopes

Scopes limit your client application’s access to end users' resources. For a deep dive on how scopes work, see the Scopes section.

Grant types

Grant types, also known as grant flows, describe how your application or service access gets an access token. To help you choose one, see the summary of grant types in the OAuth 2.0 Grant Flows section.

Claims

Claims convey information about the end user to your client application or service. For a deep dive on claims, see the Claims section.

Access tokens

Your applications and services use access tokens when making requests on behalf of a user. Tokens provide proof that your application or service is authorized to access the end user’s data. For a deep dive on access tokens, see AM as the Authorization Server section.

Keys

Keys protect sensitive information Identity Cloud needs to both send and receive. For a deep dive on keys and keystores, see the Configuring Secrets, Certificates, and Keys section.

Test SAML2 SSO using JSP flows

Overview

SAML v2.0 helps organizations share, or federate identities and services, without having to manage the identities or credentials themselves.

These instructions describe how to launch an SP-initiated JSP flow to test SAML 2 SSO. Identity Cloud acts as the authentication service provider (SP) in a circle of trust (CoT). For this test, a standalone AM instance acts as the identity provider (IDP).

Before identities can be federated in a CoT, an AM module named Federation must be present in the SP configuration. By default, the Federation module is ready-to-use in standalone AM instances. But, in Identity Cloud AM instances, you must manually create a module named Federation when you create an SP circle of trust.

Step 1: Set up an SP and an IDP

  1. Set up the Identity Cloud AM instance as a service provider:

    1. In the Identity Cloud Admin UI, go to
      Native Consoles > Access Management > Realm Name > Applications > Federation > Entity Providers.

    2. Click + Add Entity Provider.

      Enter entity provider details:
      • Entity provider type: Hosted.

      • Entity ID: Enter a unique identifier. Example: Cloud-SP.

      • Meta Alias: Provide an SP alias. Example: cloud-sp.

    3. After you’ve created an SP, export its SP metadata to an XML file.
      Example export metadata URL: https://<tenant-FQDN>/am/saml2/jsp/exportmetadata.jsp?entityid=<SP-Entity-ID>&realm=/alpha.

  2. Set up standalone the AM instance as an identity provider:

    1. In the standalone AM Admin UI, go to
      Top Level Realm > Applications > Federation > Entity Providers. Click + Add Entity Provider.

      Enter entity provider details:
      • Entity provider type: Choose Hosted.

      • Entity ID: Enter a unique identifier. Example: AM-IDP.

      • Meta Alias: Provide an IDP alias. Example: am-idp.

    2. After you’ve created an IDP, export its IDP metadata to an XML file.
      Example export metadata URL: https://<IDP-host-FQDN>/openam/saml2/jsp/exportmetadata.jsp?entityid=<IDP-Entity-ID>.

  3. In Identity Cloud, add a remote entity provider by importing the IDP metadata.

    1. In the Identity Cloud Admin UI, go to
      Native Consoles > Access Management > Realm Name > Authentication > Federation > Entity Providers.

    2. Click + New Entity Provider.

    3. Import the IDP metadata.

  4. In the standalone AM Admin UI, add a remote entity provider by importing the SP metadata.

    1. In the standalone AM Admin UI, go to:
      Top Level Realm > Authentication > Federation > Entity Providers.

    2. Click + New Entity Provider.

    3. Import the SP metadata.

  5. Create a user profile on both the SP and the IDP:

    1. SP: In the Identity Cloud AM Admin UI, go to Identities > Manage.

      • Click + New Alpha-realm-User, and enter user details.

      • Click Save.

    2. IDP: In the standalone AM Admin UI, go to Identities > Manage.

      • Click + Add New Identity, and enter user details.

      • Click Create.

Step 2: Create an SP circle of trust

  1. In the Identity Cloud Admin UI, create a circle of trust.

    1. Go to
      Native Consoles > Access Management > Realm Name > Applications > Circles of Trust.

    2. Click + Add Circle of Trust.

    3. On the New Circle of Trust page, provide a name, then click Create.

    4. On the CoT page, provide CoT details.

      CoT details:
      • Description: Enter a unique identifier.

      • Entity Providers: Choose the entity IDs for the SP and IDP.
        Examples: Cloud-SP AM-IDP

    5. Click Save Changes.

  2. In the Identity Cloud Admin UI, create a federation module.

    1. Go to
      Native Consoles > Access Management > Realm Name > Authentication > Modules.

    2. On the Modules page, click Add Module. Enter module details:

      • Name: Must be named Federation.

      • Type: Must be type Federation.

    3. Click Save Changes.

  3. Configure a relay state URL.
    This is the target end-user page the browser will display upon successful SSO.

    1. In the Identity Cloud Admin UI, go to
      Native Consoles > Access Management > Realm Name > Applications > Federation > Entity Providers.

    2. For this example, in the Cloud-SP entity provider details page, search for Relay State URL List.
      Enter the target URLs for the SP end-user sign-in page.
      Example: https://<tenant-FDQN>/enduser/?realm=alpha#/dashboard.

    3. Click Save Changes.

Step 3: Create an IDP circle of trust

  1. In the standalone AM Admin UI, create a circle of trust. Go to
    Top Level Realm > Applications > Circles of Trust.

  2. Click + Add Circle of Trust.

  3. On the New Circle of Trust page, provide a name, then click Create.

  4. On the CoT page, provide CoT details.

    CoT details:
    • Description: Enter a unique identifier.

    • Entity Providers: Choose the entity IDs for the SP and IDP.
      Examples: Cloud-SP AM-IDP.

  5. Click Save Changes.

Step 4: Test SAML2 SSO

  1. Launch an SP-initiated JSP flow.
    In a browser, to go the launch JSP URL. Example:
    https://<tenant-FQDN>/am/saml2/jsp/spSSOInit.jsp?realm=/alpha/&metaAlias=/alpha/cloud-sp&idpEntityID=AM-IDP&binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST&NameIDformat=urn:oasis:names:tc:SAML:2.0:nameid-format:persistent&RelayState=https://<tenant-FQDN>/enduser/?realm=alpha#/dashboard.

  2. On the IDP sign-in page, enter the user’s credentials:

    1. Keep this session open.

    2. The IDP authenticates the user, then the browser redirects the user back to the SP sign-in page.

  3. On the SP sign-in page, enter the user’s credentials:

    • After this second successful authentication, the user’s SP identity is linked to, or federated with, the user’s IDP identity.

    • The browser redirects to the SP end-user page.

  4. Sign the user out of both SP and IDP.

  5. Go to the IDP end-user sign-in page, and enter user’s credentials.
    The user is successfully authenticated.

  6. The browser redirects to the SP end-user page specified in the Relay State URL field.

Gateways & Agents

Overview

Integrate Identity Cloud with ForgeRock Identity Gateway and policy agents to secure access to your web resources.

ForgeRock Identity Gateway

ForgeRock Identity Gateway (IG) integrates your web applications, APIs, and microservices with Identity Cloud. IG enforces security and access control without modifying your applications or the containers where they run—whether on premises, in a public cloud, or in a private cloud.

Based on reverse proxy architecture, IG intercepts client requests and server responses. In this process, IG enforces user or service authentication and authorization to HTTP traffic. Identity Cloud acts as the authentication and authorization provider.

IG can also conduct deep analysis, then throttle and transform requests and responses when necessary.

See the ForgeRock Identity Gateway Identity Cloud Guide for these detailed instructions and examples:

Policy agents

ForgeRock policy agents are Access Management (AM) add-on components. They operate as policy enforcement points (PEPs) for websites and applications.

Policy agents natively plug into web or applications servers. The agents intercept inbound requests to websites, and interact with AM to:

  • Ensure that clients provide appropriate authentication.

  • Enforce AM resource-based policies.

Use Web Agents to protect services and web resources hosted on a web or proxy server. Use Java Agents to protect resources hosted on application or portal servers.

Although both agents enforce authentication and authorization to protected resources, they differ in the way they derive policy decisions and enforce them.

See these guides for examples of how to transition from on-premises access management to ForgeRock Identity Cloud without changing the architecture of the agent-based model:

Password Policy

Overview

Configure a password policy when you want a customized rule for creating valid sign-in passwords. The rule—or policy— applies to users who sign into your registered apps within a realm.

You can configure only one password policy per realm.

By default, Identity Cloud password policy is set to the minimum security requirements established by the National Institute of Standards and Technology (NIST). Any changes you make to the password policy must conform to requirements contained in their guidelines. See Digital Identity Guidelines.

Configure a password policy

  1. In the Identity Cloud Admin UI, go to Policy > Password Policy.

  2. Choose the realm the password policy will apply to.

  3. Edit password policy details.

    Password length

    Minimum 8 characters. No maximum.

    Cannot include

    An enabled option restricts the use of:
    ・More than 2 consecutive characters (Example: aaaaaa)
    ・Commonly-used passwords (Examples: qwerty or 12345678)
    ・Part of Alpha realm - User attributes
        From the drop-down list, specify user attributes that cannot be used.

    Must contain

    An enabled option requires at least 1:
    ・Upper case letter
    ・Lower case letter
    ・Number
    ・Space, pipe, or special character:
        ( ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { } ~ ) .

    Cannot reuse

    When enabled, restricts user from reusing the specified number of previously set passwords.

    Force password change

    When enabled, requires user to reset their password after the specified number of days has elapsed.

  4. Click Save.

Journeys

Overview

Identity Cloud comes with pre-configured end-user journeys (formerly called trees). A journey is an end-to-end workflow invoked by an end user or device. Common journeys are account registration and sign-in, for example. Identity Cloud provides templates for common end-user journeys.

You can use the drag-and-drop journey editor to configure or modify any of the ready-to-use journey templates.

Use only JavaScript for scripting. Identity Cloud does not support any other scripting languages.

Authentication template

Use the Login authentication template to configure sign-in journeys.

User self-service templates

Use a self-service template to let end users manage their accounts or resolve simple password issues without having to engage a tenant administrator.

Custom journey

Start with a blank canvas when you want to build a custom journey. Drag and drop nodes from the Journeys palette.

Default end-user journey

This is the journey Identity Cloud displays to your end users when they access your default webpage URL. For example, application webpages commonly display a Sign-In link. When the user clicks the link, the Login journey is invoked by default.

There are two ways to set a default end-user journey:

  • To set a new end-user journey as the default:
    In the New Journey dialog box, or in the Duplicate Journey dialog box, enable the option: Default journey for end users.

  • To set an existing end-user journey as the default:
    In the Identity Cloud Admin UI, click Journeys to view the Journeys list.
    Find the existing journey you want to set as the default. Then from its More (⋯) menu, choose Set as default.

Device profiling support

Use the ForgeRock SDKs to create authentication journeys based on device context. See Configure Device Profiling Authentication.

Authentication templates

Login

Create a basic Login journey to let end users authenticate and sign into your app or service using username and password.

Show me the default login journey:
login
  1. In the Identity Cloud Admin UI, go to Journeys > Login.

  2. Click Edit.

  3. Enter details for each node in the Login journey:

  4. To test the journey, copy the Preview URL, and paste the URL into a browser using Incognito or Browsing mode.

  5. When you’re satisfied with your journey, click Save.

Device profiling

Use the ForgeRock SDK to create journeys that let inanimate objects authenticate based on device context. Cell phones and smartwatches are examples of devices that have own identities. Device context provides Identity Cloud with information about how or where a device is used to authenticate.

For detailed instructions, see Configure Device Profiling Authentication.

User self-service templates

Registration

Create a registration journey to let end users create their own account for your app or service.

Show me the default registration journey:
register
  1. In the Identity Cloud Admin UI, go to Journeys > Registration.

  2. Click Edit.

  3. Enter details for each node in the Registration journey.

  4. To test the journey, copy the Preview URL, and paste the URL into a browser using Incognito or Browsing mode.

  5. When you’re satisfied with your journey, click Save.

Progressive profile

Create a Progressive Profile journey to when you want to trigger a conditional event in the end user’s journey.

The default journey triggers a reminder for the end user to set their preferences for receiving news and special offers. The reminder is displayed only if the end user logs in three times without selecting preferences. If the end user makes no selection, the reminder expires and is not displayed again. If the end user selects one or more options, the preferences get set in the end-user’s profile.

Show me the default progressive profile journey:
progressive login
  1. In the Identity Cloud Admin UI, go to Journeys > Progressive Profile.

  2. Click Edit.

  3. Provide details for these nodes in the Progressive Profile journey:

  4. In the Identity Cloud Admin UI, go to Journeys > Progressive Profile.

  5. Provide details for these nodes in the Progressive Profile journey:

  6. To test the journey, copy the Preview URL, and paste the URL into a browser using Incognito or Browsing mode.

  7. When you’re satisfied with your journey, click Save.

Update password

Create an Update Password journey to let end users change their existing passwords. End users may be required to change their password at regular intervals. Or they might have to change a password that’s been compromised.

  1. In the Identity Cloud Admin UI, go to Journeys > Update Password.

  2. Click Edit.

  3. Provide details for these nodes in the Update Password journey:

  4. To test the journey, copy the Preview URL, and paste the URL into a browser using Incognito or Browsing mode.

  5. When you’re satisfied with your journey, click Save.

Reset password

Create a Reset Password journey to let end users change their existing passwords. End users typically reset their passwords when they’ve forgotten the password they set.

Show me the default reset password journey:
reset password
  1. In the Identity Cloud Admin UI, go to Journeys > Reset Password.

  2. Click Edit.

  3. Provide details for these nodes in the Reset Password journey:

  4. To test the journey, copy the Preview URL, and paste the URL into a browser using Incognito or Browsing mode.

  5. When you’re satisfied with your journey, click Save.

Forgotten username

Create a Forgotten Username journey to let end users retrieve their username from their user account data.

Show me the default forgotten username journey:
forgot username
  1. In the Identity Cloud Admin UI, go to Journeys > Forgotten Username.

  2. Click Edit.

  3. Provide details for these nodes in the Forgotten Username journey:

  4. To test the journey, copy the Preview URL, and paste the URL into a browser using Incognito or Browsing mode.

  5. When you’re satisfied with your journey, click Save.

Custom journeys

Create a custom journey when none of the ready-to-use templates suits your needs.

  1. In the Identity Cloud Admin UI, click Journeys.

  2. Click + New Journey.

  3. Enter journey details.

    Journey Details:
    • Name: Name to display in the Journeys list.

    • Identity Object: Identifier for the user or device to authenticate

    • (Optional) Description: Summarize end-user interaction.

    • (Optional) Tags: For organizing journeys to make them easier to find.

  4. Click Create journey.

  5. Use the journey editor to create your custom journey.
    Drag nodes from the palette and arrange them on the blank canvas.

  6. Provide information for each node.
    For information about all available nodes, see Authentication Nodes Configuration Reference.

  7. To test the journey, copy the Preview URL, and paste the URL into a browser using Incognito or Browsing mode.

  8. When you’re satisfied with your journey, click Save.

Duplicate journeys

Make a duplicate journey when you want to preserve a template for future use. For example, if you are testing a journey, start with a duplicate. Be sure to give the duplicate journey a unique name.

You can create a duplicate journey in two ways:

  • Click Journeys to view the existing journeys list.
    Find the template name. Then click its More (⋯) menu, and choose Duplicate.

  • If you’re using the Journey editor, click More (⋯), and choose Duplicate.

More information

For deep dives into how the journey editor works, see:

Roles and Assignments

Overview

Roles and assignments let you to create an entitlements structure that fits the needs of each realm.

Identity architects usually build the entitlements structure, and may also use the native AM and IDM consoles to put more complex entitlements in place.

Once your entitlements structure is in place, you can use the Identity Cloud Admin UI to:

  • Add new user profiles, device profiles, or roles

  • Add assignments to roles

  • Make changes to existing user profiles, device profiles, roles, or assignments

  • Provision identities with role-based permissions

Roles

Roles define privileges for user and device identities. Roles let you automatically update privileges in numerous identity profiles. All role members receive the same permissions you’ve defined for the role. When you change the privileges for that role, you change the permissions for all role members.

When you add a role to an identity profile, the user or device becomes a member of the role. A user or device can belong to many roles.

A role won’t work until you link it to at least one assignment. During the authorization process, Identity Cloud evaluates permissions based on:

  • Roles a user or device belongs to

  • Assignments attached to their roles

binaandsam2

Internal roles

Internal roles, also called authorization roles, control access to your identity platform. You use internal roles to authorize administrators to manage your tenant or identities contained in it.

External roles

External roles, also called provisioning roles, give users and devices the permissions they need to access apps and services. You use external roles to let employees access intranet applications. You can also use external roles to let your customers and their end users access web services and mobile apps in your tenant.

Assignments

You create an assignment when you want to give a user or device permission to access a resource they need to do a job. A resource might be any of these: an application or service; data contained in a document or a database; a device such as a printer or cell phone.

An assignment won’t work without a role. A role-assignment relationship is not fully formed until you do two things:

Assignment linked to role

Link an assignment to a role. Identity Cloud grants the permissions defined in the assignment to all members of the linked role.

Assignment mapped to attribute

Map your tenant assignment to an attribute stored in an external system. An external system can be, for example, an intranet Reporting App with its own database of user accounts.

map2app2

In this illustration, Bina’s Accountant II role links to three assignments. During data store sync, Identity Cloud provisions her Reporting App user account based on assignment-attribute mappings:

Mapping From Assignment Attribute Mapping To Reporting App Description and Provisioning Outcome

Assignments: Reporting App

UserName

The mapping sets the value of Bina’s Name ("Bina Raman") in the UserName attribute in the Reporting App.

This gives Bina access to the app itself.

Assignments: Operations Reports

Reports: Operations

The mapping adds the value "Operations" to the Reports attribute in the Reporting App.

This gives Bina access to Operations reports in the Reporting App.

Assignments: Sales Reports

Reports: Sales

The mapping adds the value "Sales" to the Reports attribute in the Reporting App.

This gives Bina access to Sales reports.

You can create any number of assignments in your tenant. You can link an assignment to one or more external roles. You cannot link assignments to internal roles.

How provisioning works

When you add a user or device to a role, Identity Cloud updates the user or device profile with the role information. The update gives, or provisions, the user or device with the permissions that come with the role and its assignments.

Here’s a simple entitlement schema example:

Roles

Accountant-I
Accountant-II

Accountant-I Assignments

Reporting App
Operations Reports

Accountant-II Assignments

Reporting App
Operations Reports
Sales Reports

Sam and Bina are co-workers. Their identity profiles are provisioned with permissions based on the entitlements schema example.

  • Sam is a member of the Accountant I role.
    The Accountant I role assignments give Sam permission to use the Reporting app to access only Operations Reports.

  • Bina is a member of the Accountant II role.
    The Accountant II role assignments give Bina permission to use the Reporting app to access both Operations Reports and Sales Reports.

For a deep dive, see the following documents:

Organizations

Create organizations when you want to group identities to suit your business needs.

For example, you can build an organization structure modeled after your brand hierarchy. This lets you control access to business applications with tailored login experiences. You can also use organizations to delegate user administration.

If you go to Identities > Manage in the Identity Cloud Admin UI, but you don’t see Organizations on the Manage Identities page, then your environment has not received the organization model. But, you can download an organizations script with instructions for running it. See How do I get the organization model in my Identity Cloud environment?

An organizations use case

Here’s an example to help explain organization concepts. MightyBank is a conglomeration of independently-operated banks. MightyBank organizes its business units into two locales based on banking regulations associated with each locale. Within a business unit, each bank brand is a self-contained organization.

This diagram depicts MightyBank’s hierarchy of realms and organizations for identity management:

idcloudui concepts organizations hierarchy

MightyBank organized their Identity Cloud tenant similarly to their business units. The Alpha realm contains MightyBank identities in the Americas. The Bravo realm contains MightyBank identities in Europe, the Middle East, and Africa (EMEA). Identities represent all employees, contractors, partners, vendors, customers—anyone who conducts business for or with MightyBank.

Each organization in the hierarchy has a designated owner. An owner can create child organizations, or sub-organizations. Owners can also add administrators to their organizations and sub-organizations.

Organization administrators manage user identities within organizations. Administrators also delegate administration to individual users through roles and assignments.

Users who belong to an organization are known as members of the organization.

Top-level organizations

Only Identity Cloud tenant administrators can create top-level organizations. In this example, Sam Carter is an Identity Cloud tenant administrator. Sam has created a top-level organization in each realm.

Sam can view and manage all identities within both the Alpha and Bravo realms:

idcloudui concepts orgs sam alpha bravo realms

Sam delegates organization administration by setting up organization owners, who in turn set up organization administrators.

Owners

The main job of organization owners is to create organizations and sub-organizations. They also designate users, within the organizations they own, as administrators. Users who are authorized to manage identities within organizations are called organization administrators.

In this example, Sam designated Alma as owner of the top-level organization in the Alpha realm. Alma grouped identities into sub-organizations. One sub-organization contains Acme Bank identities. A second sub-organization contains MexBanco identities.

Alma is authorized to manage the MightyBank Americas organization, and all its sub-organizations.

idcloudui concepts orgs aspreckles realm

Organization owners can do the following, but only within the organizations and sub-organizations they own:

In this example, before Alma can add a user profile to the Acme Bank organization, the user must belong to MightyBank Americas, the parent organization. If a user doesn’t belong to the parent organization, then Alma can open the Acme Bank organization, and create a new user profile directly in the organization.

Administrators

The main job of organization administrators is to manage user identities within an organization or sub-organization.

In this example, Alma designated Barbara as the administrator for MightyAmericas. Barbara is authorized to manage all identities in the MightyAmericas organization, and in all of its sub-organizations.

Barbara then delegated administration to two employees in the Acme Bank organization, and two employees in the MexBanco organization. These delegated administrators share responsibility for managing identities.

idcloudui concepts orgs bjensen admin

Organization administrators can do the following, but only within the organizations they are authorized to manage:

In this example, before an administrator can add a user profile to the Acme Bank organization, the user profile must already belong to MightyBank Americas, the parent organization. If a user profile does not already belong in MightyBank Americas, then the administrator can open the Acme Bank organization and create a new user profile directly in the organization.

Each organization administrator can manage user profiles, but in only the organization they’re authorized to manage.

More information

Manage Identities

Your tenant might contain data about employees, customers, and devices like cell phones or printers. Each has its own identity—​a unique combination of defining attributes. Identity Cloud stores these attributes in identity profiles.

You can specify roles and assignments in a user or device identity profile. roles and assignments define the type and extent of access permissions you want a user or device to have. Identity Cloud uses roles and assignments to provision an identity profile with the permissions a user or device needs to access resources.

View identity resources

To view and manage user profiles, roles, and assignments in your tenant:
In the Identity Cloud Admin UI, go to Identities > Manage.

  • Resources are grouped by realm. If you can’t find a particular resource, be sure that you’re looking in the correct realm.

  • To view a list of only tenant administrators, see View the administrators list.

  • To view realm settings, see Realm settings.

Users

A user can be a customer, employee, vendor — a person — whose identity profile, is stored in your tenant. A user identity profile is also called a user profile.

Create a user profile

  1. In the Identity Cloud Admin UI, go to Identities > Manage.

  2. On the Manage Identities page, click Users > + New User.

  3. In the New User page, enter user details.

    User details:
    • Username: Name to be displayed in Users list

    • Password: Created by user

    • First Name: User’s given name

    • Last Name: User’s surname

    • Email Address: Provided by user

  4. Click Create User.

Edit a user profile

  1. In the platform console, go to Identities > Manage.

  2. In the Users list, click a username.

  3. In the User profile, edit user details.

    User details:
    Details
    To reference these field names in scripts or API calls, see User Identity Properties and Attributes Reference.

    Username
    First Name
    Last Name
    Email address
    Password
    Telephone Number
    City
    Postal Code
    Country
    State/Province
    Manager

    Generic Indexed String (up to 5)
    Generic Unindexed String (up to 5)
    Generic Indexed Multivalue (up to 5)
    Generic Unindexed Multivalue (up to 5) Generic Indexed Date (up to 5)
    Generic Unindexed Date (up to 5)
    Generic Indexed Integer (up to 5)
    Generic Unindexed Integer (up to 5)

    Preferences
    • Send me news and updates (Disabled by default)

    • Send me special offers and services (Disabled by default)

    Provisioning Roles

    Also known as external roles.

    • Provisioning role Type: Choose from available options.

    • Assign role only during a selected time period. (Disabled by default)

    Authorization Roles

    Also known as internal roles.

    • Authorization role Type: Choose from available options.

    Direct Reports
    • Username

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

More Options
  • To reset a user’s password, click Password Reset.
    In the Reset Password dialog box, enter a new password. Then click Reset Password to save the new password.

  • To end a user’s session, click End Sessions.
    This clears the user’s open SSO sessions within the current realm, and revokes the session tokens. The user must reauthenticate to create a new SSO session. This is useful for testing and troubleshooting purposes.

    The following knowledge base article describes how to use the AM Admin UI to view a user’s active session details: https://backstage.forgerock.com/knowledge/kb/article/a15540427.

  • To delete a user, click Delete Realm Name - User.

    You cannot undo the Delete operation.

For a deep dive into Identity Platform user identities, see "Managed Users".

Roles

For a quick take, see Roles.

Create an external role

  1. In the platform console, click go to Identities > Manage > External Roles.

  2. Click + New External Role.

  3. In the New External Role card, enter role details.

    External role details:
    • Role Name:

    • Role Description:

  4. Click Next.

  5. Choose one or more role assignments, then click Next.

  6. (Optional) Enable dynamic role assignment.

    Dynamic role conditions
    • Use the choosers to define a condition for automatically adding assigning a user to a role.

    • To add more conditions, click Add (+).

    • Click Advanced Editor to create a query-based condition.

    When you’re satisfied with your role conditions, click Next.

  7. (Optional) Enable a role time constraint.

    Role time constraints
    • Use the calendar and clock choosers to define when the role is in effect.

      • Specify the time zone to be used for the start date/time and end/date you specified. Choose a time zone relative to Greenwich Mean Time (GMT). GMT is the same as Universal Time Coordinated (UTC).

      • Click Time zones chart to calculate the offset time.

  8. Click Save Role.

  9. (Optional) To add a member to a role, in the Members list, click + Add Members.

    1. Use the chooser to select one or more users to add to the role members list.

    2. Click + Add members.

Edit an external role

  1. In the Identity Cloud Admin UI, go to Identities > Manage > External Roles.

  2. In the external roles list, click the role name.

  3. In the External Role card, click Members.

    • To add a member, in the Members list, click + Add Members.

      1. Use the chooser to select one or more users to add to the role members list.

      2. Click +Add members.

    • To edit a member profile, in the Members list, find the member username.
      In the same row, click More () and choose Edit.

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

Create an internal role

  1. In the platform console, go to Identities > Manage> Internal Roles.

  2. Click + New Internal Role.

  3. In the New Internal Role card, enter role details.

    Internal role details:
    • Role Name: Unique identifier to display in the Roles list.

    • Role Description: String that’s meaningful to your organization.
      Examples: Employee, Customers, Sales Department, Europe

  4. Click Next.

  5. Choose the type of identities (users or devices) you want to define permissions for, then click Add.

  6. In the Role Permissions card, enable the permissions you want to grant to this identity type (Users or Devices). You can grant permissions to view, create, update, or delete resources in your extranet.

  7. To grant attribute-based or filter-based permissions, click Advanced.

    Attribute-Based Permissions

    By default, each identity with this role in its profile has Read-only access to your resources.
    For each identity attribute in this list, you can:

    • Add additional write access by choosing Read/Write

    • Restrict access completely by choosing None.

    Filter-Based Permissions

    You are giving permission to any identity with this role in its profile that also meets the conditions you specify here. The permissions you give here overrides the view, create, update, or delete options you enabled for this role.

    1. Use the slider to enable Filter-based Permissions.

    2. Use the choosers to specify additional conditions for granting permission.

    3. (Optional) Click Advanced Editor to create a query-based condition.

    4. Click Next.

  8. (Optional) Enable a role time constraint for this role.

    Role time constraints
    • Use the calendar and clock choosers to define when the role is in effect.

      • Specify the time zone to be used for the start date/time and end/date you specified.

        Choose a time zone relative to Greenwich Mean Time (GMT). GMT is the same as Universal Time Coordinated (UTC).

      • Click Time zones chart to calculate the offset time.

  9. Click Save Role.

  10. To add a member, in the Members list, click +Add Members.

    1. Use the chooser to select one or more identities to add to the role members list.

    2. Click Add members.

Edit an internal role

  1. In the Identity Cloud Admin UI, go to Identities > Manage > External Roles.

  2. In the internal roles list, click the role name.

  3. In the Internal Role card, click Members.

    • To add a member, in the Members list, click +Add Members.

      1. Use the chooser to select one or more users to add to the role members list.

      2. Click + Add members.

    • To edit a member profile, in the Members list, find the member username.
      In the same row, click More (), and choose Edit.

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

For a deep dive into roles, see Roles.

Assignments

For a quick take, see Assignments.

Create an assignment

  1. In the platform console, go to Identities > Manage > Assignments.

  2. Click +New Assignment.

  3. In the New Assignment card, choose the source-target mapping you want to use for synchronizing identity data stores.

    Tell me more

    The first column lists your tenant data stores. The second column lists available target data stores. For more information, see "Assignments"§.

  4. Click Next.

  5. In the Assignment Details card, enter Assignment details.

    Assignment details:
    • Assignment: Name to be displayed in Assignments list

    • Assignment Description: The permission this assignment provides.
      For example, Allows access to Reporting App.

  6. Click Next.

  7. To provision an attribute in the target data store, click Add an attribute. Then enter attribute details.

    Attribute details:

    Create an attribute-value pair for provisioning the target user account.

    1. From the Attribute menu, choose an identity attribute in your tenant.

    2. In the Value field, enter a value for the attribute you just chose. This attribute-value pair will be synced with user accounts in the target data store.

    3. Click Assignment Operations (settings).
      Define how Identity Cloud will sync assignment attributes on the target data store:

      • The On Assignment menu defines what Identity Cloud will do with a new assignment attribute.

        • The Merge with target option adds a new attribute value to an existing attribute in the target user account.

        • The Replace target option removes the existing attribute-value pair in the target user account, and replaces it with the attribute-value you’ve defined.

      • The On Unassignment menu defines what Identity Cloud will do with an existing assignment attribute.

        • The Remove from target option deletes the specified attribute-value pair from the target user account.

        • The No operation option preserves the attribute-value pair in your tenant identities and in the target user accounts.

      • To add more assignment attributes, click Add (+)

      • To remove an assignment attribute, click Delete (-).

  8. Click Save Assignment.

Edit an assignment

  1. In the Identity Cloud Admin UI, go to Identities > Manage > Assignments.

  2. In the Assignments list, click the assignment name.

  3. Click Details to edit assignment details.

    Assignment details:
    • Mapping: The source and target data stores to be synced for this assignment. The first column lists your identity platform data store. The second column lists a data store that contains user accounts outside your tenant.

    • Assignment Details: Edit the name or description to suit your needs.

  4. To provision an attribute in the target data store, click Add an attribute. Then enter attribute details.

    Attribute details:

    Create an attribute-value pair for provisioning the target user account.

    1. From the Attribute menu, choose an identity attribute in your tenant.

    2. In the Value field, enter a value for the attribute you just chose. This attribute-value pair will be synced with user accounts in the target data store.

    3. Click Assignment Operations (settings).
      Define how Identity Cloud will sync assignment attributes on the target data store:

      • The On Assignment menu defines what Identity Cloud will do with a new assignment attribute.

        • "Merge with target" adds a new attribute value to an existing attribute in the target user account.

        • "Replace target" removes the existing attribute-value pair in the target user account, and replaces it with the attribute-value you’ve defined.

      • The On Unassignment menu defines what Identity Cloud will do with an existing assignment attribute.

        • The Remove from target option deletes the specified attribute-value pair from the target user account.

        • The No operation option preserves the attribute-value pair in your tenant identities and in the target user accounts.

      • To add more assignment attributes, click Add (+)

      • To remove an assignment attribute, click Delete (-).

    4. Click Save.

  5. (Optional)To use a script to customize an assignment, click + Add an event script.

    Tell me more
    1. On the Add Event Script card, choose the event to trigger your script.

    2. Provide your script to Identity Cloud in one of these ways:

      • Enter your script in the text box, and indicate the script Type: JavaScript. Groovy is not supported this time.

      • Enable Upload File, and specify the script filename.

    3. (Optional) Use the Variables fields to define variables in your script.
      Enable JSON to enter your variables using the JSON format.

    4. Click Save.

  6. Click Roles to view roles linked to this assignment:

    1. To add a new role, click +New Role.

    2. To edit an existing role, click More ().

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

For a deep dive into roles and assignments, see Use Assignments to Provision Users.

Organizations

For a quick take, see Organizations.

Managing Organizations

Tenant administrators:
  • Using the REST APIs:

  • Using the Identity Cloud Admin UI:

    • In the Identity Cloud Admin UI, go to Identities > Manage > Realm - Organizations. Follow the steps described on this page.

Organization owners and organization administrators:
  • Using the Identity Cloud End User UI:

    • In the Identity Cloud End User UI, go to Realm - Organizations. Follow the steps described on this page.

Before you begin

You can build organizations in many different ways. For example, you can start with a parent organization that contains all user identities, and then build your organization hierarchy. Or, you can first build a hierarchy of empty organizations and sub-organizations, and then add users to the various target organizations. Regardless of the approach you take, at some point you’ll have to import identities into an organization.

Import identities into an organization

Tenant administrators Organization owners Organization administrators

  • Only tenant administrators can import identities into an organization.

Tenant administrators:

In this example:

  • A .csv file containing 100 user identities already exists.

  • A parent organization containing no members already exists.

To import identities:

  1. In the Identity Cloud Admin UI, go to Identities > Import.

  2. On the Import Identities page, click + New Import.

  3. In the Upload CSV menu, select Realm - Users.

  4. Click Next.

    300

  5. In the Upload CSV dialog box, enter upload details:

    CSV File

    Enter the name of your .csv file containing identities to import.

    Match Using

    Enter a property name to use for matching and filtering objects. In this example, userName is used to import user profiles that will become members of the target organization.

  6. Click Next.

  7. When the Import Complete dialog box displays, and you can confirm that the import was successful, click Done.

  8. Verify that users were imported to the organization your created:

    1. In the Identity Cloud Admin UI, go to Identities > Manage > Realm - Users.

    2. Open any user’s profile, and click Organizations to which I Belong. In the organizations list, you should see the name of the organization you created.

    3. Go to Identities > Manage > Realm - Organizations. In the organizations list, you should see the name of the organization you created.

    4. Click the name of the organization you created, then click Members. In the list of members, you should see all the user identities you imported into the organization.

Create a parent organization

Tenant administrators Organization owners Organization administrators

  • Only tenant administrators can create a parent organization.

Tenant administrators:
  1. In the Identity Cloud Admin UI, go to Identities > Manage > Realm - Organizations.

  2. On the Organizations page, click + New Organization.

  3. In the New Realm - organization page, enter the following:

    Name

    Enter a display name. Uppercase, lowercase, alphanumeric & special characters, and white spaces are allowed.

  4. Click Save. This saves the new organization, then immediately opens the new organization profile to edit:

    Name

    Update if necessary, see step 3.

    Description

    Enter a description meaningful to you.

    Parent Organization

    Leave empty to designate the new organization as a parent organization.

  5. Click Save.

Create an organization owner

Tenant administrators Organization owners Organization administrators

  • Only tenant administrators can create an organization owner.

Tenant administrators:
  1. In the Identity Cloud Admin UI, go to Identities > Manage > Realm - Organizations.

  2. In the organizations list, click the name of the organization you want to add an owner to.

  3. Click Owner, then click + Add Owner.

  4. In the Add Owner dialog box, in the Owner search field, choose the name of the user you want to designate as the organization owner.

    Do not make an organization owner a member of the organization. This can result in giving the organization administrator greater control of the organization than its owner.

  5. Click Save.

Create an organization administrator

Tenant administrators Organization owners Organization administrators

  • Tenant administrators can create an organization administrator in any organization.

  • Organization owners can create an organization administrator only within organizations or sub-organization where they are the owner.

  • Organization administrators cannot create other organization administrators.

Tenant administrators:
  1. In the Identity Cloud Admin UI, go to Identities > Manage > Realm - Organizations.

  2. In the organization list, click the name of the organization you want to add an administrator to.

  3. Click Administrators.

  4. Click + Add Administrators.

  5. In the Add Administrators dialog box, enter a username in the Administrators search field. The user must already belong to the organization.

  6. Click Save. The username or usernames you added now display in the members list.

Organization owners:
  1. In the Identity Cloud End User UI, go to Realm - Organizations.

  2. Follow steps 2–6 in the tenant administrator instructions above.

Create a sub-organization

Tenant administrators Organization owners Organization administrators

  • Tenant administrators can create a sub-organization within any organization.

  • Organization owners can create a sub-organization only within organizations or sub-organizations where they are the owner.

  • Organization administrators can create a sub-organization only within organizations or sub-organizations where they are an administrator.

Tenant administrators:
  1. Follow the instructions to create a parent organization.

  2. In step 4, set a parent organization as follows:

    Parent Organization

    Enter the name of an existing organization one level up from this child organization.

    Tenant administrators have visibility of all organizations.
Organization owners and organization administrators:
  1. In the Identity Cloud End User UI, go to Realm - Organizations.

  2. On the Organizations page, click + New Organization.

  3. In the New Realm - organization page, enter the following:

    Name

    Enter a display name. Uppercase, lowercase, alphanumeric & special characters, and white spaces are allowed.

    Parent Organization

    Enter the name of an existing organization one level up from this child organization.

    Organization owners and organization administrators have visibility only of the organizations and sub-organizations that they own or administrate.
  4. Click Save. This saves the new organization, then immediately opens the new organization profile to edit:

    Name

    Update if necessary, see step 3.

    Description

    Enter a description meaningful to you.

    Parent Organization

    Update if necessary, see step 3.

  5. Click Save.

Edit an organization or sub-organization

Tenant administrators Organization owners Organization administrators

  • Tenant administrators can edit any organization or sub-organization.

  • Organization owners can only edit organizations or sub-organization where they are the owner.

  • Organization administrators can only edit organizations or sub-organization where they are an administrator.

Tenant administrators:
  1. In the Identity Cloud Admin UI, go to Identities > Manage > Realm - Organizations.

  2. In the organizations list, click the name of the organization profile you want to edit.

  3. In the organization profile page, edit organization details.

    Name

    Enter a display name. Uppercase, lowercase, alphanumeric characters, special characters, and white spaces are allowed.

    Description

    Enter a description meaningful to you.

    Parent Organization

    Enter the name of the organization one level up from this child organization, or leave empty to designate the organization as a parent organization.

  4. Click Save.

Organization owners and organization administrators:
  1. In the Identity Cloud End User UI, go to Realm - Organizations.

  2. In the organizations list, click the name of the organization profile you want to edit.

  3. In the organization profile page, edit organization details.

    Name

    Enter a display name. Uppercase, lowercase, alphanumeric characters, special characters, and white spaces are allowed.

    Description

    Enter a description meaningful to you.

    Parent Organization

    Enter the name of the organization one level up from this child organization.

  4. Click Save.

Add or create organization members

Tenant administrators Organization owners Organization administrators

  • Tenant administrators have access the members of all organizations.

  • Organization owners have access to only the members in organizations they own.

  • Organization administrators have access to only the members in their administrative area.

Add a member to an organization
Tenant administrators:
  1. In the Identity Cloud Admin UI, go to Identities > Manage > Realm - Organizations.

  2. In the organizations list, click the name of the organization you want to add a member to.

  3. On the Organizations page, click Members.

  4. Click + Add Members.

  5. In the Add Members dialog box, enter names of users to add to this organization in the search field.

  6. Click Save. The username or usernames you added now display in the members list.

Organization owners and organization administrators:
  1. In the Identity Cloud End User UI, go to Realm - Organizations.

  2. Follow steps 2–6 in the tenant administrator instructions above.

Create a new user profile in an organization
Tenant administrators:
  1. In the Identity Cloud Admin UI, go to Identities > Manage > Realm - Users.

  2. In the Realm - User list, click + New Realm - User.

  3. In the New Realm - User dialog box, enter user profile details.

    Username

    Enter a unique username. No white spaces.

    First Name

    Enter the user’s given name.

    Last Name

    Enter the user’s surname.

    Email Address

    Enter the user’s email address.

  4. Click Save. The new user profile is displayed in the Realm - Users list.

  5. Open the new user’s identity profile.

  6. Click Organizations to which I Belong.

  7. Click + Add Organizations to which I Belong.

  8. In the Add Organization to which I Belong dialog box, choose an existing organization from the search field. You can choose more than one.

  9. Click Save.

Organization owners and organization administrators:
  1. In the Identity Cloud End User UI, go to Realm - Users.

  2. Follow steps 2–9 in the tenant administrator instructions above.

Delete an organization

Tenant administrators Organization owners Organization administrators

  • Tenant administrators can delete any organization or sub-organization.

  • Organization owners can only delete organizations or sub-organization where they are the owner.

  • Organization administrators can only delete organizations or sub-organization where they are an administrator.

Tenant administrators:
  1. In the Identity Cloud Admin UI, go to Identities > Manage > Realm - Organizations.

  2. In the organizations list, click the name of the organization you want to delete.

  3. On the Realm - Organization page, click Delete Realm - Organization.

    This operation cannot be undone.
Organization owners and organization administrators:
  1. In the Identity Cloud End User UI, go to Realm - Organizations.

  2. Follow steps 2–3 in the tenant administrator instructions above.

Sync Identities

Overview

Register a remote server with your tenant when you want to sync identities, or set up load balancing and failover.

This page provides instructions for setting up a connector server using the Identity Cloud Admin UI. You can also create a connector configuration over REST.

Connectors can read data in your tenant, and can read data in an external resource. An external resource is an app or service that runs on a resource server outside your tenant. Use connectors to convert your identity profiles, as well user accounts in a resource server, into a format that both data stores can use.

For a quick take, see About Identity Cloud connectors on this page.

Before you begin

Before you can make a connection, you have to register a remote connector server with your tenant. You also need to have a connector service up and running.

Here’s an overview of the steps to take:

  1. Register a remote server.

  2. Download a remote server.

  3. Configure the remote server to connect to Identity Cloud.

  4. Install and configure a connector.

  5. Create a mapping between identities in Identity Cloud and identities in your identity resource server.

  6. (Optional) If you plan to set up load balancing or failover, then register a remote server cluster.

Register a remote server

  1. In the Identity Cloud Admin UI, go to Identities > Connect > Connector Servers.

  2. Click + New Connector Server.

  3. In the New Connector Server dialog box, provide the remote server details:

    • Name: This name is displayed in the Connector Servers list.
      Use only lowercase letters and numerals. No special characters or spaces allowed.

  4. Click Save.

When the remote server is successfully registered, you’ll see links to the Next Steps. Be sure to open each link in a different window or tab so have you always have access to the Next Steps dialog box.

connector next steps

Completing the Next Steps

1 Reset the client secret

Identity Cloud creates an OAuth 2.0 client for you, and opens its profile.

client secret

  1. Click Reset to change the client secret.

  2. In the Reset Client Secret dialog box, enter any string to serve as a password.

  3. Read the warning, and then click Save.

2 Download a remote server

You’re directed to the Identity Cloud connectors download page.

  1. Download the Remote Connector Server (Java).

    Download the OpenICF package to the host that will run the connector server.
    You can run the connector server on the same host as the identity resource server. Or, you can run it on a different host. For example, you could run the connector server on a host that’s dedicated to only connectors.

  2. Configure the remote server.

3 Install and configure a connector

You’re directed to the Supported Connectors page.

(Optional) If the connector you want to use is not bundled with the remote server you downloaded in Next Step 2, you’ll need these instructions. Choose a connector, and follow the instructions for downloading and installing it.

After you complete the Next Steps, click Done.

Configure a remote server

  1. Unpack the OpenICF package you downloaded from the IDM Connectors download page.

  2. Edit the ConnectorServer.properties file.

    ConnectorServer.properties details:
    1. Add the OAuth2 Client credentials used to obtain an OAuth2 token. The client uses the Client Credentials grant type.

      • connectorserver.clientId=RCSClient
        Identity Cloud created this OAuth 2 client for you.

      • connectorserver.clientSecret=<client-secret>
        Use the OAuth 2 client secret you entered for RCSClient.

    2. Uncomment these settings and edit them for your tenant:

      • connectorserver.url
        This is the Identity Cloud OpenICF endpoint.
        Use wss over HTTPS so the client can obtain a bearer token through OpenID.

        • In staging and production environments, use three URLs in a space-delimited list. Example:
          connectorserver.url=wss://<tenant-name>.forgerock.io/openicf/0 wss://<tenant-name>.forgerock.io/openicf/1 wss://<tenant-name>.io/openicf/2

        • In a development environment, use only one URL. Example:
          connectorserver.url=wss://<tenant-name>.forgerock.io/openicf/0

      • connectorserver.connectorServerName=<remote-server-name>
        This is the remote server name you set through the Identity Cloud Admin UI. Be sure the name includes only lowercase letters and numerals. No special characters or spaces allowed.

      • connectorserver.pingPongInterval=60
        The WebSocket Ping/Pong interval (seconds).

      • connectorserver.housekeepingInterval=20
        The WebSocket connections housekeeping interval (seconds).

      • connectorserver.groupCheckInterval=900
        WebSocket groups check interval, in seconds.

      • connectorserver.webSocketConnections=3
        Specifies the number of sockets the connector server will establish and maintain to each IDM it connects to.

      • connectorserver.connectionTtl=3000
        WebSocket connection’s time to live (seconds).

      • connectorserver.newConnectionsInterval=10
        Time between new connections (seconds).

      • connectorserver.tokenEndpoint=https://<tenant-name>.forgerock.io/am/oauth2/realms/root/realms/alpha/access_token
        Token endpoint to retrieve access token.

      • connectorserver.scope=fr:idm:*
        OAuth2 token scope.

      • connectorserver.usessl=true
        Enables SSL.

      • connectorserver.loggerClass=org.forgerock.openicf.common.logging.slf4j.SLF4JLog

  3. When you’re satisfied with your changes, save the file.

  4. Start the remote server on the OAuth 2.0 client:

    Windows

    bin\ConnectorServer.bat /run

    Linux

    bin/ConnectorServer.sh /run

  5. To verify that the connection is working, view the remote server status in the Remote Servers list.

Create a mapping

Create a mapping between identities in Identity Cloud, and identities in your identity resource server.

  1. In the Identity Cloud Admin UI, go to Native Consoles > Identity Management.

  2. In the IDM Admin UI, click Create Mapping.
    For detailed information and instructions, see Configure a Resource Mapping.

Once you’ve tested your mapping configuration per the instructions, you can make connections for synchronizing and provisioning user profiles.

Register a server cluster

This is optional. Use a cluster of remote servers when you want to set up load balancing or failover among multiple resource servers.

  1. In the Identity Cloud Admin UI, go to Identities > Connect > Server Clusters.

  2. Click + New Server Cluster.

  3. Provide Server Cluster Details:

    Connector Cluster Details
    • Name: Identifier to display in the Server Clusters list.

    • Algorithm:

      • Choose Failover if you want requests to be redirected to a designated server only when the primary server fails.

      • Choose Round Robin if you want to continuously load-balance among two or more servers regardless of service status.

  4. Click Next.

  5. In the Choose Servers dialog box, enable the connectors you want to include in the server cluster.

    All connectors in a server cluster must be of the same type such as LDAP, Salesforce, and so forth. If a server cluster contains a connector that is not the same type as the others in the cluster, the different connector will not work.

  6. Click Create Cluster.

Synchronize passwords

You can synchronize hashed user passwords from your ForgeRock® Directory Services deployment into Identity Cloud.

Password synchronization relies on an LDAP connector configured to synchronize accounts from your DS servers. Identity Cloud password synchronization does not use a password synchronization plugin. Instead, it synchronizes hashed passwords as strings in the same way it synchronizes other LDAP attributes.

This feature depends on having compatible one-way hash password storage schemes in Identity Cloud and in your DS password policies. DS servers in Identity Cloud verify user-provided plaintext passwords against the password hash, just as the DS servers in your deployment.

  1. Verify that your DS service stores the passwords you want to synchronize only with DS password storage schemes that are also enabled in Identity Cloud.

    The following DS password storage schemes are enabled in Identity Cloud:

    • Bcrypt

    • PBKDF2

    • PBKDF2-HMAC-SHA256

    • PBKDF2-HMAC-SHA512

    • Salted SHA-256

    • Salted SHA-512

    • SCRAM-SHA-256

    • SCRAM-SHA-512

  2. Verify that account synchronization works properly from your DS service to Identity Cloud.

    For example, modify a test user’s entry in your DS server, and check that the corresponding account in Identity Cloud is correctly updated after reconciliation runs.

  3. In the native IDM Admin UI, configure the LDAP connector to synchronize userPassword attributes as strings:

    1. Delete __PASSWORD__ from the list of LDAP connector properties.

    2. Add userPassword with Native type: string and Run as User enabled.

  4. In the native IDM Admin UI, configure the mapping from your remote DS system resource to Identity Cloud managed users:

    1. Map userPassword in your remote DS system resource to password in managed users.

    2. Set the transformation script for the synchronization to the following inline script, of type JavaScript:

      // Set the text of {ds_abbr} userPassword as the value of the password:
      if (source != null) {
        var base64 = Packages.org.forgerock.util.encode.Base64url;
        decodedTarget = new Packages.java.lang.String(base64.decode(source));
        target = decodedTarget;
      }
  5. Verify that password synchronization is working correctly.

    For example, modify a test user’s password in your DS server, and check that the user can authenticate in Identity Cloud after reconciliation runs.

About Identity Cloud connectors

Your tenant administrators use Identity Cloud by accessing your tenant. But, non-administrators and customers sign in to applications other than Identity Cloud itself. Apps and services that run and store data outside your tenant exist as external resources relative to Identity Cloud.

Identity Cloud provides connectors to synchronize your identity profiles with data stored in your resource servers.

Connectors work differently based on the capabilities of the connected resource server. For a summary of supported connectors and their capabilities, see Supported Connectors.

Syncing and provisioning

Here’s how Identity Cloud synchronizes user data. In this diagram, an identity resource server hosts an app and a data store containing user accounts. The resource server also hosts a connector server. The connector server runs a connector.

When you edit a user’s account on the resource server, the connector makes the change in the user’s profile in your tenant.

idcloud connector server

The opposite also happens. When you edit a user’s profile in your tenant, the connector makes the change in the user’s account in your resource server. For a quick take on Identity Cloud syncing and provisioning, see a related example in "Assignments".

Data reconciliation

Identity Cloud reconciles data when changes occur in either your identity profiles or in user accounts stored in resource servers.

An Identity Cloud connector first compares an identity profile to its corresponding user account in the resource server. If conflicting information exists, Identity Cloud resolves the conflicts based on your preferences. Then Identity Cloud updates both the identity profile and the user account.

Load balancing and failover

Use a connector server cluster (a cluster of connector servers) when you want to set up load balancing or failover. A connector server cluster connects to multiple resource servers.

When you configure the connector server cluster for load balancing, Identity Cloud distributes incoming authentication or authorization requests among the clustered servers. The connector service determines where a request is directed. Request traffic flows evenly, and no single connector works faster or more slowly than others in the server cluster. This ensures that requests are handled with the greatest efficiency.

When you configure connector servers for failover, if one resource server stops, then your Identity Cloud redirects requests to a standby resource server. This ensures that your end users don’t experience a loss of service. When the stopped resource server restarts, Identity Cloud directs requests to the restarted server.

More information

For a deep dive, see the following documents:

Bulk Import Identities

Overview

You can use a CSV file to bulk import identities. This is useful when you want to add a large number of identities to a role or assignment at one time.

Import identities in bulk

Before you begin:
You’ll need a CSV file containing the identity profiles you want to import. The file must comply with this CSV template example:

CSV template example
{
  "_id": "template",
  "header": "\"userName\",\"givenName\",\"sn\",\"mail\",\"description\",\"accountStatus\",\"telephoneNumber\",
 \"postalAddress\",\"address2\",\"city\",\"postalCode\",\"country\",\"stateProvince\",\"preferences/updates\",
 \"preferences/marketing\""
}

Be sure to use commas as separators. Any other separator may cause errors.

For information about generating this file, see Import Bulk Data.

  1. In the Identity Cloud Admin UI, go to Identities > Import.

  2. On the Import Identities page, click + New Import.

  3. On the New Import dialog box, select the realm-target you want to import to.

    Tell me more

    The target can be any managed object such as a user, role, or assignment defined within a realm. For example, you could import ten user profiles to the Bravo-realm Roles target. The imported user profiles are added to the bravo-role managed object in Identity Cloud.

  4. Click Next.

  5. (Optional) If you haven’t already generated a CSV file, click the CSV Template link to download an example file.

    If you use this file:

    • Replace the attributes in this file with attributes in your identity resource server.

    • Delete all unused attributes.

  6. Enter the name of the CSV file to upload.

  7. Choose a property Identity Cloud can use to match an entry in the CSV file to an identity profile in your realm-target.

    Tell me more

    For example, you could choose the username property. If username bjensen exists in your CSV file, Identity Cloud tries to verify that a user profile with the username bjensen also exists in your tenant. If verified, then Identity Cloud updates the entire bjensen user profile. If no match is found, then Identity Cloud creates a user profile for bjensen.

  8. Click Next.

    The Import Complete dialog box indicates real-time import progress. When the import is complete, Identity Cloud displays the number of new, updated, unchanged, and failed imports.

  9. (Optional) To download a CSV file containing a list of identity profiles that failed to import, click Download CSV.

  10. Click Done.

For a deep dive into bulk import information, see Import Bulk Data.

View or delete a CSV file

  1. In the Identity Cloud Admin UI, go to Identities > Import.

  2. On the Import Identities list, find the filename.
    In the same row, click More ().

  3. Choose View Details or Delete.

Configure UI for Identities

Identity Cloud lets you configure how the Identity Cloud Admin UI behaves when managing identities.

The configuration settings are applied to the UI for tenant administrator users and delegated end users. They are global, so apply to all realms.

View configuration

The configuration settings are grouped by identity profile, so they can be set independently for users, roles, assignments, and so on.

To view the configuration for an identity profile:

  1. In the Identity Cloud Admin UI, go to Identities > Configure to view a list of identity profiles.

  2. Click on an identity profile. For example, if you want to configure the UI for managing user identities, click Users.

Configuration settings

General settings

Require UI Search Filter

This setting will apply a minimum length filter to an identity search field before performing a search operation. This speeds up the time to retrieve records where there is a large identity data set.

To apply a UI search filter to an identity profile:

  1. Follow the steps above to view configuration for the identity profile you want to change; for example, user identities.

  2. Check the Require UI Search Filter checkbox.

  3. Enter a number greater than zero in the Minimum Characters field.

  4. Click Save.

Then, to check that the UI search filter has been applied:

  1. Go to Identities > Manage, and select the identity profile that corresponds to the one you configured in the previous steps.

  2. Enter a term in the Search field, and ensure that results are returned only when the minimum number of characters have been entered.

User Identity Properties and Attributes Reference

Overview

You can customize Identity Cloud display names in user profiles, or reference them in scripts and API calls. However, the property and attribute names are not consistent between IDM and AM. To address this, the reference tables below show the equivalent IDM property name and AM attribute name for each Identity Cloud custom display name.

Using the reference tables

  • If you write scripts for AM that access user profiles, then use AM attribute names. User profile script examples: OAuth2 access token modification; OIDC claims; decision node scripts for authentication journeys (formerly trees).

  • If you write scripts for IDM that access managed objects, then use IDM property names. Managed object script examples: onUpdate, onCreate, onDelete, and so forth.

  • If you use APIs to access managed objects or user profiles:

    • Calls to /openidm APIs must use IDM property names.

    • Calls to /am APIs must use AM attribute names.

If you use the IDM native console to change a Display Name, the change will reflect in both the IDM and Identity Cloud Admin UIs. But, on the API side and in scripts, the generic names will remain unchanged.

Reference tables

User details

Display Name IDM Property AM Attribute

Username

userName

uid

Common Name

cn

cn

Password

password

userPassword

Status

accountStatus

inetUserStatus

First Name

givenName

givenName

Last Name

sn

sn

Email Address

mail

mail

Description

description

description

Telephone Number

telephoneNumber

telephoneNumber

Address 1

postalAddress

street

City

city

l

Postal Code

postalCode

postalCode

Country

country

co

State/Province

stateProvince

st

Display Name

displayName

displayName

Provisioning Roles

roles

fr-idm-managed-user-roles

Manager

manager

fr-idm-managed-user-manager

Authorization Roles

authzRoles

fr-idm-managed-user-authzroles-internal-role

Effective Roles

effectiveRoles

fr-idm-effectiveRole

Effective Assignments

effectiveAssignments

fr-idm-effectiveAssignment

Last Sync timestamp

lastSync

fr-idm-lastSync

KBA

kbaInfo

fr-idm-kbaInfo

Preferences

preferences

fr-idm-preferences

Consented Mappings

consentedMappings

fr-idm-consentedMapping

Description IDM Property AM Attribute

User Metadata

_meta

fr-idm-managed-user

Immutable IDM attribute

_id

fr-idm-uuid

Revision attribute

_rev

etag

Generic extension attributes

Strings
Display Name IDM Property AM Attribute

Generic Indexed String 1

frIndexedString1

fr-attr-istr1

Generic Indexed String 2

frIndexedString2

fr-attr-istr2

Generic Indexed String 3

frIndexedString3

fr-attr-istr3

Generic Indexed String 4

frIndexedString4

fr-attr-istr4

Generic Indexed String 5

frIndexedString5

fr-attr-istr5

Generic Unindexed String 1

frUnindexedString1

fr-attr-str1

Generic Unindexed String 2

frUnindexedString2

fr-attr-str2

Generic Unindexed String 3

frUnindexedString3

fr-attr-str3

Generic Unindexed String 4

frUnindexedString4

fr-attr-str4

Generic Unindexed String 5

frUnindexedString5

fr-attr-str5

Multivalues
Display Name IDM Property AM Attribute

Generic Indexed Multivalue 1

frIndexedMultivalued1

fr-attr-imulti1

Generic Indexed Multivalue 2

frIndexedMultivalued2

fr-attr-imulti2

Generic Indexed Multivalue 3

frIndexedMultivalued3

fr-attr-imulti3

Generic Indexed Multivalue 4

frIndexedMultivalued4

fr-attr-imulti4

Generic Indexed Multivalue 5

frIndexedMultivalued5

fr-attr-imulti5

Generic Unindexed Multivalue 1

frUnindexedMultivalued1

fr-attr-multi1

Generic Unindexed Multivalue 2

frUnindexedMultivalued2

fr-attr-multi2

Generic Unindexed Multivalue 3

frUnindexedMultivalued3

fr-attr-multi3

Generic Unindexed Multivalue 4

frUnindexedMultivalued4

fr-attr-multi4

Generic Unindexed Multivalue 5

frUnindexedMultivalued5

fr-attr-multi5

Dates
Display Name IDM Property AM Attribute

Generic Indexed Date 1

frIndexedDate1

fr-attr-idate1

Generic Indexed Date 2

frIndexedDate2

fr-attr-idate2

Generic Indexed Date 3

frIndexedDate3

fr-attr-idate3

Generic Indexed Date 4

frIndexedDate4

fr-attr-idate4

Generic Indexed Date 5

frIndexedDate5

fr-attr-idate5

Generic Unindexed Date 1

frUnindexedDate1

fr-attr-date1

Generic Unindexed Date 2

frUnindexedDate2

fr-attr-date2

Generic Unindexed Date 3

frUnindexedDate3

fr-attr-date3

Generic Unindexed Date 4

frUnindexedDate4

fr-attr-date4

Generic Unindexed Date 5

frUnindexedDate5

fr-attr-date5

Integers
Display Name IDM Property AM Attribute

Generic Indexed Integer 1

frIndexedInteger1

fr-attr-iint1

Generic Indexed Integer 2

frIndexedInteger2

fr-attr-iint2

Generic Indexed Integer 3

frIndexedInteger3

fr-attr-iint3

Generic Indexed Integer 4

frIndexedInteger4

fr-attr-iint4

Generic Indexed Integer 5

frIndexedInteger5

fr-attr-iint5

Generic Unindexed Integer 1

frUnindexedInteger1

fr-attr-int1

Generic Unindexed Integer 2

frUnindexedInteger2

fr-attr-int2

Generic Unindexed Integer 3

frUnindexedInteger3

fr-attr-int3

Generic Unindexed Integer 4

frUnindexedInteger4

fr-attr-int4

Generic Unindexed Integer 5

frUnindexedInteger5

fr-attr-int5

UI Integration Options for Identity Cloud

Overview

When you integrate your applications with your Identity Cloud tenant, you will need to consider how to manage the journey and account pages that your end users will use. There are a number of user interface (UI) options available, and the one you choose will be based on a combination of the following factors:

  • Hosting: Do you want to host your own UI?

  • Application platform: Do you only need to support web applications, or do you also need to support native applications?

  • Theming: How much control do you want over the look and feel of the UI?

  • Journey flow: Do you want to redirect end users to a central UI, or embed a UI into each application?

For a quick take on these factors against each of the UI options, see the summary below.

Journey flows

Centralized journey flows

Centralized journey flows are an increasingly familiar sign-in experience to end users and are considered a security best practice. An example of a centralized journey flow is Google G Suite, where a user is redirected to the same authentication page no matter which application they are trying to access.

Centralized journey flows are possible using all UI options.

Embedded journey flows

Embedded journey flows offer a more traditional sign-in experience, as end users are not redirected outside an application. However, embedded journey flows are not considered a security best practice, as individual applications then have access to both the user’s credentials and to the authorization grant.

Embedded journey flows are not recommended, but are possible using the self-hosted Login UI or SDKs.

UI options

Identity Cloud hosted pages

This is the easiest option, as your Identity Cloud tenant already provides hosted pages that allow you to manage:

  • End user journey pages, such as login, registration, and password reset

  • End user account pages, such as user profile and delegated administration

The UI layout is fixed, but can be themed per realm. You can add company logos and change button, link, and background colors. The UI supports web applications but not native applications.

This option is useful if you have limited theming needs or want to quickly try new registration or authentication flows without integrating them into an application.

This option only lets you use centralized journey flows in your applications, as embedded journey flows are not supported. Additionally, this is the only option that supports SAML journey flows that use Identity Cloud as the IDP.

Self-hosted ForgeRock Login UI and ForgeRock End User UI

For background information on the ForgeRock Login UI (Login UI) and ForgeRock End User UI (End User UI), see https://backstage.forgerock.com/docs/platform/7.1/platform-setup-guide/#platform-ui.

In this option, you self-host one or both of the Login UI and End User UI, and configure them to use your Identity Cloud tenant.

This option offers flexibility if you want to customize the layout of the UIs or customize the theming beyond what is provided by the default hosted pages. The UIs support web applications but not native applications.

This option also lets you use both centralized and embedded journey flows in your applications.

ForgeRock SDKs

For background information on ForgeRock SDKs (SDKs), see https://sdks.forgerock.com/getting-started/using-sdks/.

In this option, you use the SDKs to develop your own custom UI for web, Android, or iOS applications. You then integrate it with your Identity Cloud tenant using the REST API.

Each SDK provides an out-of-the-box UI module (FRUI) that allows you to prototype your custom UI. However, it is only provided as a starting point and is not intended for production use.

This option offers maximum flexibility if you want to customize the behavior, layout, and theming of the UI, or want to support Android and iOS applications. However, it requires a higher level of technical skill than the other options.

It also lets you use both centralized and embedded journey flows in your applications.

Summary

UI Application Platform Theming Journey Flows Notes

Identity Cloud hosted pages

Web

Limited

Centralized

  • Default UI for your Identity Cloud tenant

  • Allows rapid journey prototyping

Self-hosted Login UI
Self-hosted End User UI

Web

No limitation

Centralized or embedded

  • Choice of self-hosting one or both of the UIs

SDKs

Web, Android, iOS

No limitation

Centralized or embedded

  • Higher level of technical skill required

Identity Cloud Hosted Pages

Overview

Identity Cloud hosts default web pages you can use in end-user journeys. The pages are designed to help you quickly create and test common user self-service operations.

For example, the default login journey starts with a sign-in page for capturing username and password. The journey ends with the end-user’s profile page.

600

But, if you don’t want to risk exposing information contained in the default end-user profile, you can deactivate its hosted page. Then you can use the ForgeRock SDKs or your own APIs to create and host your own custom web pages.

When the Hosted Pages option is deactivated, this web page is displayed to unauthorized users:

450

By deactivating the default end-user profile, you can still use the hosted end-user journey UI, while denying unauthorized access to end-user profiles. Your customers manage only their own profiles, or delegate administration, using your application.

When you deactivate hosted pages, all hosted pages associated with your tenant are deactivated.

See the Journeys page for an explanation of how hosted pages are integrated into default journeys.

Activate or Deactivate Hosted Pages

hosted pages on

  1. In the Identity Cloud Admin UI, open the Tenant menu and go to Tenant Settings > Global Settings.

  2. Click Hosted Pages.

  3. On the Hosted Pages page:

    • To activate hosted pages, click Activate.

    • To deactivate hosted pages, click Deactivate.

The change takes effect immediately.

When you deactivate hosted pages, all hosted pages associated with your tenant are deactivated.

See the Journeys page for an explanation of how hosted pages are integrated into default journeys.

Localize ForgeRock End User and Login UIs

Overview

Identity Cloud lets you localize the ForgeRock End User and Login UIs (UIs) to support the different languages of your end users. You do this with translation configuration, defining a locale-specific set of key/phrase translation pairs that override the default set of key/phrase pairs. You can override some or all of the default keys, in as many locales as you need. The translation configuration has an effect in all realms.

The UIs try to find a translation configuration for the locale requested by an end user’s browser, or gracefully fall back to the default en locale.

To manage translation configuration, use the /openidm/config/uilocale/* endpoint in the REST API.

Translation configuration format

The translation configuration format for each locale is as follows:

{
    "enduser": { (1)
        "pages": {
            "dashboard": {
                "widgets": {
                    "welcome": {
                        "greeting": "Translation for predefined 'greeting' key", (2)
                    }
                }
            }
        }
    },
    "login": { (1)
        "login": {
            "next": "Translation for predefined 'next' key" (2)
        },
        "overrides": {
            "UserName": "Translation for literal phrase 'User Name'", (3)
            "Password": "Translation for literal phrase 'Password'" (3)
        }
    },
    "shared": { (1)
        "sideMenu": {
            "dashboard": "Translation for predefined 'dashboard' key" (2)
        }
    }
}
1 Top-level blocks

The enduser, login, and shared top-level blocks correspond to the names of the UI packages in GitHub:

2 Key/phrase translation pairs with predefined keys

Most of the key/phrase translation pairs are predefined in the en locale translation files for each package:

You can translate some or all of the keys. Additionally, if you want to create different translations in the enduser and login blocks for a key from the shared block, you can copy the JSON structure for the shared key into each of the enduser and login blocks, where they will override the key in the shared block.

3 Key/phrase translation pairs with literal keys

Key/phrase translation pairs defined within an override block are not predefined. Instead, the key is made from a literal phrase with all non-alphanumeric characters (including underscores) stripped out.

These translation pairs with literal keys are designed as a catch-all solution for any UI phrases that have not been defined, or for any unlocalized phrases that come directly from the backend servers. The example shows two literal keys that translate the placeholder text from input fields that are part of an authentication journey. This approach can be taken to translate server output from authentication messages and journey nodes.

Translation pairs with literal keys are currently only available within the login top-level block.

Translation precedence

The UIs translate each key/phrase pair in a particular order. They initially determine a primary locale using the requested language from an end user’s browser. Then, if no translation is found using the primary locale, they fall back to the default en locale.

The translation precedence for an end user with a browser locale of fr (French) would be as follows:

  • Attempt to use the primary fr locale:

    1. Look for the translation key in any translation configuration for the fr locale:
      https://<tenant-name>.forgeblocks.com/openidm/config/uilocale/fr

  • Fall back to the default en locale:

    1. Look for the translation key in any translation configuration for the en locale:
      https://<tenant-name>.forgeblocks.com/openidm/config/uilocale/en

    2. Look for the translation key in the translation files for the en locale :

      • platform-enduser/src/locales/en.json

      • platform-login/src/locales/en.json

      • platform-shared/src/locales/en.json

REST API

Create or replace translation configuration

  1. Create an access token. See Get an access token.

  2. Create or replace the translation configuration for each locale:

    Show request
    curl \
    --request PUT 'https://<tenant-name>.forgeblocks.com/openidm/config/uilocale/<locale>' \ (1)
    --header 'Authorization: Bearer <access-token>' \ (2)
    --header 'Content-Type: application/json' \
    --data-raw '{ (3)
        "enduser": {
            "pages": {
                "dashboard": {
                    "widgets": {
                        "welcome": {
                            "greeting": "Bonjour"
                        }
                    }
                }
            }
        },
        "login": {
            "login": {
                "next": "Suivant"
            },
            "overrides": {
                "UserName": "Nom d'utilisateur",
                "Password": "Mot de passe"
            }
        },
        "shared": {
            "sideMenu": {
                "dashboard": "Tableau de bord"
            }
        }
    }
    '
    1 Replace <locale> with a locale identifier. Some examples are:
    • en (English)

    • es (Spanish)

    • fr (French)

    • en-us (English - United States)

    • es-ar (Spanish - Argentina)

    • fr-ca (French - Canada)

    2 Replace <access-token> with the access token.
    3 Replace the example translation configuration with your own translation configuration.
    Show response
    {
        "_id": "uilocale/fr",
        "enduser": {
            "pages": {
                "dashboard": {
                    "widgets": {
                        "welcome": {
                            "greeting": "Bonjour"
                        }
                    }
                }
            }
        },
        "login": {
            "login": {
                "next": "Suivant"
            },
            "overrides": {
                "UserName": "Nom d'utilisateur",
                "Password": "Mot de passe"
            }
        },
        "shared": {
            "sideMenu": {
                "dashboard": "Tableau de bord"
            }
        }
    }

View translation configuration

An access token is not needed to to view the translation configuration as it is publicly accessible.
  1. View the translation configuration using a GET request:

    Show request
    curl \
    --request GET 'https://<tenant-name>.forgeblocks.com/openidm/config/uilocale/<locale>' (1)
    1 Replace <locale> with a locale identifier.
    Show response
    {
        "_id": "uilocale/fr",
        "enduser": {
            "pages": {
                "dashboard": {
                    "widgets": {
                        "welcome": {
                            "greeting": "Bonjour"
                        }
                    }
                }
            }
        },
        "login": {
            "login": {
                "next": "Suivant"
            },
            "overrides": {
                "UserName": "Nom d'utilisateur",
                "Password": "Mot de passe"
            }
        },
        "shared": {
            "sideMenu": {
                "dashboard": "Tableau de bord"
            }
        }
    }

Delete translation configuration

  1. Create an access token for the realm where the translations are applied. See Get an access token.

  2. Delete the translation configuration:

    Show request
    curl \
    --request DELETE 'https://<tenant-name>.forgeblocks.com/openidm/config/uilocale/<locale>' \ (1)
    --header 'Authorization: Bearer <access_token>' \ (2)
    1 Replace <locale> with a locale identifier.
    2 Replace <access-token> with the access token.
    Show response
    {
        "_id": "uilocale/fr",
        "enduser": {
            "pages": {
                "dashboard": {
                    "widgets": {
                        "welcome": {
                            "greeting": "Bonjour"
                        }
                    }
                }
            }
        },
        "login": {
            "login": {
                "next": "Suivant"
            },
            "overrides": {
                "UserName": "Nom d'utilisateur",
                "Password": "Mot de passe"
            }
        },
        "shared": {
            "sideMenu": {
                "dashboard": "Tableau de bord"
            }
        }
    }

Apply Custom Themes to ForgeRock End User and Login UIs

Overview

The ForgeRock End User and Login UIs have a default theme that includes the logos, colors of buttons and links, and so on. This default theme applies to the entire realm. You can add custom themes so that your end users are presented with screens specific to their authentication journey.

Custom themes let you create a different look and feel for each brand that you support, including different profile page layouts, logos, headers, and footers.

A theme is followed throughout an authentication journey. This means that if a user logs in through the Login UI with a specific theme, the remaining pages in the journey will have that same theme.

Add a custom theme

In the Identity Cloud Admin UI:

  1. Select Hosted Pages > + New Theme.

    You can also duplicate an existing them by clicking next to the theme you want, then selecting Duplicate.

  2. Enter a theme name that describes the theme’s purpose; for example, the brand associated with that authentication journey.

  3. The following pages let you customize various aspects of the theme:

    • Styles lets you set the color of text, links, menus, buttons, and background pages.

    • Logos lets you set the logo on the login page, and other pages in the authentication journey, as well as the Favicon that is displayed for the Login and End User pages.

      Specify the URL to an image to set the Sign-in Logo and, optionally, the End User and End User Collapsed logos. Images are resized proportionately so that they are not distorted. You can resize individual logos according to where they appear in the journey. If you specify a Sign-in Logo and do not specify any of the optional logos, the Sign-in Logo is used throughout.

    • Layout lets you customize the components and layout of end-user pages:

      • For Journey pages, specify whether objects are centered, left-aligned, or right-aligned on the page, and set custom headers and footers.

        Headers and footers can take HTML or inline CSS to insert links, classes, and so on. Scripting is not currently supported in headers and footers.

      • For Account pages, specify which fields should display for end user accounts. Use this page, for example, to let users edit their passwords, trusted devices, and so on.

        The footer on this page is separate from the footer that is displayed on the Journey page. This lets you set up different buttons, links, and so on, that are displayed to a user once they have logged in.

  4. When you have completed the theme setup, click Save then Done to save the theme.

  5. To set this theme as the default theme for this realm, click …​ next to the theme, then select Set as Realm Default.

Apply a custom theme to a Journey

  1. Select Journeys, then select the journey to which you want to apply the custom theme, and click Edit.

  2. Click …​ > Edit Details then select Override theme.

  3. Select the custom theme that you want to apply to this journey, then click Save.

Theme definitions and the mappings between authentication journeys and themes are stored in Identity Cloud as configuration objects. They are therefore "static" in terms of Identity Cloud promotion. If you add a new theme or logo, your change must go through the promotion process. Theme selection can be dynamic, however. If you set a theme in a page node during a journey, for example, by setting stage var themeID=myTheme, that theme is applied dynamically for the remainder of the journey.

Scripting

Overview

You can use scripting to modify default ForgeRock Identity Cloud behavior in many situations: client-side authentication, policy conditions, handling OpenID Connect claims, and others.

You can only use JavaScript for scripting in Identity Cloud.

Managing scripts

To manage your scripts, go to Realm > Scripts.

On the scripts page you can view a list of existing scripts. To edit, duplicate, or delete a script, click its More () menu.

The edit option in the More menu will open the script in a lightweight editor which features syntax highlighting and validation checking. You can maximize the editor to full screen to assist the editing of larger scripts:

idcloudui scripts editor

1 JavaScript editor
2 Fullscreen option
3 Syntax highlighting
4 Validation checking

Create a new script

To create a new script:

  1. Go to Realm > Scripts, then click + New Script.

  2. Choose a script type:

    Script Type Description

    Client-side Authentication

    Scripts that are executed on the client during authentication.

    Journey Decision Node

    Scripts that are included in an authentication node within a journey, and are executed on the server during authentication.

    Policy Condition

    Scripts that are used as conditions within policies.

    OIDC Claims

    Scripts that gather and populate the claims in a request when issuing an ID token or making a request to the userinfo endpoint.

    OAuth 2.0 Access Token Modification

    Scripts that modify the key-value pairs contained within access tokens before they are issued to a client.

    OAuth 2.0 "May Act"

    Scripts that can add the may_act claim to tokens when performing token exchanges.

    Social Identity Provider Profile Transformation

    Scripts that adapt the fields received by a social identity provider to align with the fields expected by Identity Cloud.

  3. After you select a script type, the editor will open. The editor is prepopulated with a default script for that type, which is intended as a starting point for your custom script.

    • If you selected the wrong script type, click Previous to repeat step 2 and select a different script type.

  4. Enter a unique name for the script, then click Save.

The script type is fixed for the lifetime of the script when the script is saved.

Journey decision node scripts

See Journeys for more information on journeys.

You can create, edit, and validate journey decision node scripts directly from within a scripted decision node in a journey.

  1. Go to Realm > Journeys.

  2. Open a journey in the journey editor.

  3. Find an existing scripted decision node or add a new one.

  4. Select the scripted decision node to open the context pane on the right side.

  5. The following screenshot shows where you can create a new journey decision node script (4) or edit an existing one (5):

idcloudui journeys scripted decision script options

1 Scripted decision node
2 Context pane
3 Journey decision node script drop-down
4 Add new journey decision node script
5 Edit existing journey decision node script

Authenticate to Identity Cloud REST API

Overview

The Identity Cloud REST API has three different authentication methods, depending on what you are trying to achieve:

  • Use an API key and secret for read-only operations.
    Examples: Identity Cloud monitoring and logging.

  • Use a session token for access management operations.
    Examples: Setting up authentication journeys or policies.

  • Use an access token for identity management operations or write operations.
    Examples: Configuring user profiles, roles, or assignments.

Summary of authentication methods

The following table summarizes the REST API endpoints and their different authentication methods:

REST endpoints Authentication method
  • /monitoring/health

Not applicable (publicly accessible endpoint)

  • /monitoring

  • /logs

API key and secret:

  1. Create an API key and secret in the Identity Cloud Admin UI using a tenant administrator account.

  2. Set the API key and secret as x-api-key and x-api-secret HTTP headers for each API request:

    x-api-key: <api-key>
    x-api-secret: <api-secret>
  • /am/*

Session token:

  1. Create a session token by authenticating a username and password:

    1. For administrative actions (for example, creating an OAuth 2.0 client), authenticate an Identity Cloud tenant administrator username and password.

    2. For end-user actions, authenticate an end-user username and password.

  2. Set the session token as an HTTP header value for each API request. The HTTP header name is the tenant session cookie name (found in Tenant Settings > Global Settings > Cookie):

    <session-cookie-name>: <session-token>
  • /openidm/*

  • /.well-known/*

  • /variables

  • /secrets

  • /restart

Access token:

  1. Create a session token by authenticating an Identity Cloud tenant administrator username and password.

  2. Use the session token to create an OAuth 2.0 client with an appropriate scope (for example, fr:idm:* or fr:idc:esv:*).

  3. Create a realm user identity in the Identity Cloud Admin UI with authorization role openidm-admin.

  4. Create an access token using an OAuth 2.0 authorization grant flow. The grant flow needs to specify the credentials of the OAuth 2.0 client (step 2) and the realm user identity (step 3).

  5. Set the access token as a bearer token in the Authorization HTTP header for each API request:

    Authorization: Bearer <access-token>

Authenticate to Identity Cloud REST API with API Key and Secret

Overview

You will need an API key and secret to authenticate to the following Identity Cloud REST API endpoints:

  • /monitoring

  • /logs

Get an API key and secret

  1. In the Identity Cloud Admin UI, click the user icon, and then click Tenant Settings.

    Show me where

    tenant menu

  2. On the Global Settings tab, click Log API Keys.

  3. Click New Log API Key, provide a name for the key, and then click Create Key.

    A dialog box appears containing the new keys:

    log api key

  4. Store the api_key_id and api_key_secret values securely.

    You cannot view the api_key_secret value again once you click Done.
  5. Click Done.

Use an API key and secret

To use the API credentials, set them as x-api-key and x-api-secret HTTP headers:

Show request
$ curl \
  --request GET 'https://<tenant-name>.forgeblocks.com/monitoring/logs/sources?_prettyPrint=true' \
  --header 'x-api-key: <api-key>' \
  --header 'x-api-secret: <api-secret>'
Show response
{
    "result": [
        "am-access",
        "am-activity",
        "am-authentication",
        "am-config",
        "am-core",
        "am-everything",
        "ctsstore",
        "ctsstore-access",
        "ctsstore-config-audit",
        "ctsstore-upgrade",
        "idm-access",
        "idm-activity",
        "idm-authentication",
        "idm-config",
        "idm-core",
        "idm-everything",
        "idm-sync",
        "userstore",
        "userstore-access",
        "userstore-config-audit",
        "userstore-ldif-importer",
        "userstore-upgrade"
    ],
    "resultCount": 22,
    "pagedResultsCookie": null,
    "totalPagedResultsPolicy": "NONE",
    "totalPagedResults": 1,
    "remainingPagedResults": 0
}

Authenticate to Identity Cloud REST API with Session Token

Overview

You will need a session token to authenticate to the following Identity Cloud REST API endpoint:

  • /am/*

The /am/* endpoint exposes many, but not all, of the AM APIs to Identity Cloud. For an expanded list of endpoints, see AM REST API Endpoints.

Get a tenant administrator session token

For background information on sessions and session tokens, see Introducing Sessions.

  1. Start an authentication journey:

    Show request
    $ curl \
      --request POST 'https://<tenant-name>.forgeblocks.com/am/json/authenticate' \
      --header 'Content-Type: application/json' \
      --header 'Accept-API-Version: resource=2.1'
  2. View the response to see the authId and callbacks:

    Show response
    {
        "authId": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9... ...JgXXlA1ke3zcOuiA0CbC8EnhLX1MzIIU6VNgw4uq_Js",
        "callbacks": [
            {
                "type": "NameCallback",
                "output": [
                    {
                        "name": "prompt",
                        "value": "User Name"
                    }
                ],
                "input": [
                    {
                        "name": "IDToken1",
                        "value": ""
                    }
                ],
                "_id": 0
            },
            {
                "type": "PasswordCallback",
                "output": [
                    {
                        "name": "prompt",
                        "value": "Password"
                    }
                ],
                "input": [
                    {
                        "name": "IDToken2",
                        "value": ""
                    }
                ],
                "_id": 1
            }
        ]
    }
  3. Submit the authId and callbacks received in the previous response, specifying the username and password of an Identity Cloud tenant administrator in the callbacks:

    Show request
    $ curl \
    --request POST 'https://<tenant-name>.forgeblocks.com/am/json/authenticate' \
    --header 'Content-Type: application/json' \
    --header 'Accept-API-Version: resource=2.1, protocol=1.0' \
    --data-raw '{
        "authId": "<auth-id>", (1)
        "callbacks": [
            {
                "type": "NameCallback",
                "output": [
                    {
                        "name": "prompt",
                        "value": "User Name"
                    }
                ],
                "input": [
                    {
                        "name": "IDToken1",
                        "value": "<idcloud-tenant-administrator-user-name>"  (2)
                    }
                ],
                "_id": 0
            },
            {
                "type": "PasswordCallback",
                "output": [
                    {
                        "name": "prompt",
                        "value": "Password"
                    }
                ],
                "input": [
                    {
                        "name": "IDToken2",
                        "value": "<idcloud-tenant-administrator-password>"  (3)
                    }
                ],
                "_id": 1
            }
        ]
    }'
    1 Replace <auth-id> with authID from the response in the previous step
    2 Replace <idcloud-tenant-administrator-username> with an Identity Cloud tenant administrator username
    3 Replace <idcloud-tenant-administrator-password> with an Identity Cloud tenant administrator password
  4. View the response to see the new authId and MFA-skip callbacks:

    Show response
    {
        "authId": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9... ...AzkH7fJGh9AzcDzsqxMaJsSNgjfQ-G5vGddOScVdDVQ",
        "callbacks": [
            {
                "type": "TextOutputCallback",
                "output": [
                    {
                        "name": "message",
                        "value": "message-952"
                    },
                    {
                        "name": "messageType",
                        "value": "0"
                    }
                ]
            },
            {
                "type": "ConfirmationCallback",
                "output": [
                    {
                        "name": "prompt",
                        "value": ""
                    },
                    {
                        "name": "messageType",
                        "value": 0
                    },
                    {
                        "name": "options",
                        "value": [
                            "Set up"
                        ]
                    },
                    {
                        "name": "optionType",
                        "value": -1
                    },
                    {
                        "name": "defaultOption",
                        "value": 0
                    }
                ],
                "input": [
                    {
                        "name": "IDToken2",
                        "value": 0
                    }
                ]
            },
            {
                "type": "HiddenValueCallback",
                "output": [
                    {
                        "name": "value",
                        "value": "false"
                    },
                    {
                        "name": "id",
                        "value": "skip-input-952"
                    }
                ],
                "input": [
                    {
                        "name": "IDToken3",
                        "value": "skip-input-952"
                    }
                ]
            },
            {
                "type": "TextOutputCallback",
                "output": [
                    {
                        "name": "message",
                        "value": "var skipContainer = document.createElement(\"div\");skipContainer.style = \"width:100%\";skipContainer.innerHTML = \"<button id='skip-link-952' class='btn btn-block btn-link' type='submit'>Skip for now</button>\";document.getElementById(\"skip-input-952\").parentNode.append(skipContainer);document.getElementsByClassName(\"callback-component\").forEach(  function (e) {    var message = e.firstElementChild;    if (message.firstChild && message.firstChild.nodeName == \"#text\" && message.firstChild.nodeValue.trim() == \"message-952\") {      message.align = \"center\";      message.innerHTML = \"<h2 class='h2'>Set up 2-step verification</h2><div style='margin-bottom:1em'>Protect your account by adding a second step after entering your password to verify it's you signing in.</div>\";    }  })"
                    },
                    {
                        "name": "messageType",
                        "value": "4"
                    }
                ]
            },
            {
                "type": "TextOutputCallback",
                "output": [
                    {
                        "name": "message",
                        "value": "document.getElementById(\"skip-link-952\").onclick = function() {  document.getElementById(\"skip-input-952\").value = \"Skip\";  document.getElementById(\"loginButton_0\").click();  return false;}"
                    },
                    {
                        "name": "messageType",
                        "value": "4"
                    }
                ]
            }
        ]
    }
  5. Submit the new authId and MFA-skip callbacks received in the previous response:

    Show request
    $ curl \
    --request POST 'https://<tenant-name>.forgeblocks.com/am/json/authenticate' \
    --header 'Content-Type: application/json' \
    --header 'Accept-API-Version: resource=2.1, protocol=1.0' \
    --data-raw '{
        "authId": "<auth-id>", (1)
        "callbacks": [
            {
                "type": "TextOutputCallback", (2)
                "output": [
                    {
                        "name": "message",
                        "value": "Skip"
                    },
                    {
                        "name": "messageType",
                        "value": "0"
                    }
                ]
            },
            {
                "type": "ConfirmationCallback",
                "output": [
                    {
                        "name": "prompt",
                        "value": ""
                    },
                    {
                        "name": "messageType",
                        "value": 0
                    },
                    {
                        "name": "options",
                        "value": [
                            "Set up"
                        ]
                    },
                    {
                        "name": "optionType",
                        "value": -1
                    },
                    {
                        "name": "defaultOption",
                        "value": 0
                    }
                ],
                "input": [
                    {
                        "name": "IDToken2",
                        "value": 0
                    }
                ]
            },
            {
                "type": "HiddenValueCallback", (2)
                "output": [
                    {
                        "name": "value",
                        "value": "false"
                    },
                    {
                        "name": "id",
                        "value": "Skip"
                    }
                ],
                "input": [
                    {
                        "name": "IDToken3",
                        "value": "Skip"
                    }
                ]
            }
        ]
    }'
    1 Replace <auth-id> with authID from the response in the previous step
    2 Skip MFA callbacks
  6. View the response to see the session token, represented as tokenID:

    Show response
    {
        "tokenId": "uVB-DjIYHJb99PVeIc1Y9bcD974.*AAJTSQACMDIAAlNLABxwSExZMkZLTkwvMzFjVHIwNzIyMW5UeFJCRkk9AAR0eXBlAANDVFMAAlMxAAIwMQ..*",
        "successUrl": "/platform",
        "realm": "/"
    }

Use a tenant administrator session token

To use the session token with the REST API, set it as an HTTP header value. For the HTTP header field name, use the tenant session cookie name (found in Tenant Settings > Global Settings > Cookie).

The following example uses the session token to create a public OAuth 2.0 client:

Show request with abridged body
$ curl \
--request PUT 'https://<tenant-name>.forgeblocks.com/am/
json/realms/root/realms/<realm>/realm-config/agents/OAuth2Client/<oauth2-client-name>' \ (1) (2)
--header 'accept: application/json' \
--header 'Content-Type: application/json' \
--header '<session-cookie-name>: <session-token>' \ (3) (4)
--data-raw '{
  "coreOAuth2ClientConfig": {
    ...
    "userpassword": "<oauth2-client-password>", (5)
    "clientType": {
      "inherited": false,
      "value": "Public"
    },
    "scopes": {
      "inherited": false,
      "value": [
        "write",
        "read",
        "share",
        "print",
        "copy",
        "delete",
        "manage",
        "edit"
      ]
    },
    ...
  },
  "advancedOAuth2ClientConfig": {
    ...
    "grantTypes": {
      "inherited": false,
      "value": [
        "authorization_code",
        "implicit",
        "password",
        "client_credentials",
        "refresh_token",
        "urn:ietf:params:oauth:grant-type:uma-ticket",
        "urn:ietf:params:oauth:grant-type:device_code",
        "urn:ietf:params:oauth:grant-type:saml2-bearer",
        "urn:ietf:params:oauth:grant-type:jwt-bearer",
        "urn:openid:params:grant-type:ciba"
      ]
    },
    ...
  },
  ...
}'
1 Replace <realm> with the realm where you want to create the OAuth 2.0 client.
2 Replace <oauth2-client-name> with the name that you have chosen for the OAuth 2.0 client.
3 Replace <session-cookie-name> with the session cookie name configured for the tenant.
4 Replace <session-token> with the tokenId in the authentication response (see Get a tenant administrator session token).
5 Replace <oauth2-client-password> with the password that you have chosen for the OAuth 2.0 client.
Show request with full body
$ curl \
--request PUT 'https://<tenant-name>.forgeblocks.com/am/json/realms/root/realms/<realm>/realm-config/agents/OAuth2Client/<oauth2-client-name>' \
--header 'accept: application/json' \
--header 'Content-Type: application/json' \
--header '<session-cookie-name>: <session-token>' \
--data-raw '{
  "coreOAuth2ClientConfig": {
    "agentgroup": "",
    "status": {
      "inherited": false,
      "value": "Active"
    },

    "userpassword": "<oauth2-client-password>",
    "clientType": {
      "inherited": false,
      "value": "Public"
    },
    "loopbackInterfaceRedirection": {
      "inherited": true,
      "value": true
    },
    "redirectionUris": {
      "inherited": false,
      "value": [
        "https://httpbin.org/anything"
      ]
    },
    "scopes": {
      "inherited": false,
      "value": [
        "write",
        "read",
        "share",
        "print",
        "copy",
        "delete",
        "manage",
        "edit"
      ]
    },
    "defaultScopes": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    },
    "clientName": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    },
    "authorizationCodeLifetime": {
      "inherited": true,
      "value": 0
    },
    "refreshTokenLifetime": {
      "inherited": true,
      "value": 0
    },
    "accessTokenLifetime": {
      "inherited": true,
      "value": 0
    }
  },
  "advancedOAuth2ClientConfig": {
    "name": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    },
    "descriptions": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    },
    "requestUris": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    },
    "responseTypes": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    },
    "grantTypes": {
      "inherited": false,
      "value": [
        "authorization_code",
        "implicit",
        "password",
        "client_credentials",
        "refresh_token",
        "urn:ietf:params:oauth:grant-type:uma-ticket",
        "urn:ietf:params:oauth:grant-type:device_code",
        "urn:ietf:params:oauth:grant-type:saml2-bearer",
        "urn:ietf:params:oauth:grant-type:jwt-bearer",
        "urn:openid:params:grant-type:ciba"
      ]
    },
    "contacts": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    },
    "tokenEndpointAuthMethod": {
      "inherited": true,
      "value": "string"
    },
    "sectorIdentifierUri": {
      "inherited": true,
      "value": "string"
    },
    "subjectType": {
      "inherited": true,
      "value": "string"
    },
    "updateAccessToken": {
      "inherited": true,
      "value": "string"
    },
    "clientUri": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    },
    "logoUri": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    },
    "policyUri": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    },
    "isConsentImplied": {
      "inherited": true,
      "value": true
    },
    "mixUpMitigation": {
      "inherited": true,
      "value": true
    }
  },
  "coreOpenIDClientConfig": {
    "claims": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    },
    "postLogoutRedirectUri": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    },
    "clientSessionUri": {
      "inherited": true,
      "value": "string"
    },
    "defaultMaxAge": {
      "inherited": true,
      "value": 0
    },
    "defaultMaxAgeEnabled": {
      "inherited": true,
      "value": true
    },
    "defaultAcrValues": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    },
    "jwtTokenLifetime": {
      "inherited": true,
      "value": 0
    }
  },
  "signEncOAuth2ClientConfig": {
    "jwksUri": {
      "inherited": true,
      "value": "string"
    },
    "jwksCacheTimeout": {
      "inherited": true,
      "value": 0
    },
    "jwkStoreCacheMissCacheTime": {
      "inherited": true,
      "value": 0
    },
    "tokenEndpointAuthSigningAlgorithm": {
      "inherited": true,
      "value": "string"
    },
    "jwkSet": {
      "inherited": true,
      "value": "string"
    },
    "idTokenSignedResponseAlg": {
      "inherited": true,
      "value": "string"
    },
    "idTokenEncryptionEnabled": {
      "inherited": true,
      "value": true
    },
    "idTokenEncryptionAlgorithm": {
      "inherited": true,
      "value": "string"
    },
    "idTokenEncryptionMethod": {
      "inherited": true,
      "value": "string"
    },
    "idTokenPublicEncryptionKey": {
      "inherited": true,
      "value": "string"
    },
    "clientJwtPublicKey": {
      "inherited": true,
      "value": "string"
    },
    "mTLSTrustedCert": {
      "inherited": true,
      "value": "string"
    },
    "mTLSSubjectDN": {
      "inherited": true,
      "value": "string"
    },
    "mTLSCertificateBoundAccessTokens": {
      "inherited": true,
      "value": true
    },
    "publicKeyLocation": {
      "inherited": true,
      "value": "string"
    },
    "userinfoResponseFormat": {
      "inherited": true,
      "value": "string"
    },
    "userinfoSignedResponseAlg": {
      "inherited": true,
      "value": "string"
    },
    "userinfoEncryptedResponseAlg": {
      "inherited": true,
      "value": "string"
    },
    "userinfoEncryptedResponseEncryptionAlgorithm": {
      "inherited": true,
      "value": "string"
    },
    "requestParameterSignedAlg": {
      "inherited": true,
      "value": "string"
    },
    "requestParameterEncryptedAlg": {
      "inherited": true,
      "value": "string"
    },
    "requestParameterEncryptedEncryptionAlgorithm": {
      "inherited": true,
      "value": "string"
    },
    "tokenIntrospectionResponseFormat": {
      "inherited": true,
      "value": "string"
    },
    "tokenIntrospectionSignedResponseAlg": {
      "inherited": true,
      "value": "string"
    },
    "tokenIntrospectionEncryptedResponseAlg": {
      "inherited": true,
      "value": "string"
    },
    "tokenIntrospectionEncryptedResponseEncryptionAlgorithm": {
      "inherited": true,
      "value": "string"
    }
  },
  "coreUmaClientConfig": {
    "claimsRedirectionUris": {
      "inherited": true,
      "value": [
        "Unknown Type: any"
      ]
    }
  }
}'
Show response
{
    "_id": "<oauth2-client-name>",
    "_rev": "1969048932",
    "coreOAuth2ClientConfig": {
        "agentgroup": null,
        "userpassword": null,
        "userpassword-encrypted": "AAAAA0FFUwIQov3z9VqIAZNjEIdr9/kly8jg8irlj6shFnjsLQdtFfrTROJsaLUC0w==",
        "scopes": {
            "inherited": false,
            "value": [
                "write",
                "read",
                "share",
                "print",
                "copy",
                "delete",
                "manage",
                "edit"
            ]
        },
        "clientType": {
            "inherited": false,
            "value": "Public"
        },
        "redirectionUris": {
            "inherited": false,
            "value": [
                "https://httpbin.org/anything"
            ]
        },
        "status": {
            "inherited": false,
            "value": "Active"
        }
    },
    "advancedOAuth2ClientConfig": {
        "grantTypes": {
            "inherited": false,
            "value": [
                "authorization_code",
                "implicit",
                "password",
                "client_credentials",
                "refresh_token",
                "urn:ietf:params:oauth:grant-type:uma-ticket",
                "urn:ietf:params:oauth:grant-type:device_code",
                "urn:ietf:params:oauth:grant-type:saml2-bearer",
                "urn:ietf:params:oauth:grant-type:jwt-bearer",
                "urn:openid:params:grant-type:ciba"
            ]
        }
    },
    "_type": {
        "_id": "OAuth2Client",
        "name": "OAuth2 Clients",
        "collection": true
    }
}

Get an end-user session token

  1. Start an end-user authentication journey:

    Show request
    $ curl \
      --request POST 'https://<tenant-name>.forgeblocks.com/am/
    json/realms/root/realms/<realm>/authenticate?authIndexType=service&authIndexValue=PasswordGrant' \ (1)
      --header 'Content-Type: application/json' \
      --header 'Accept-API-Version: resource=2.1'
    1 Replace <realm> with the realm where you want to authenticate the end user.
  2. View the response to see the authId and callbacks:

    Show response
    {
        "authId": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9... ...G6ZY_vWFpsTTaewUTVk1x4diSOpc2HK8LispKh_3nBw",
        "callbacks": [
            {
                "type": "NameCallback",
                "output": [
                    {
                        "name": "prompt",
                        "value": "User Name"
                    }
                ],
                "input": [
                    {
                        "name": "IDToken1",
                        "value": ""
                    }
                ],
                "_id": 0
            },
            {
                "type": "PasswordCallback",
                "output": [
                    {
                        "name": "prompt",
                        "value": "Password"
                    }
                ],
                "input": [
                    {
                        "name": "IDToken2",
                        "value": ""
                    }
                ],
                "_id": 1
            }
        ]
    }
  3. Submit the authId and callbacks received in the previous response, specifying the username and password of an end user in the callbacks:

    Show request
    curl \
    --request POST 'https://<tenant-name>.forgeblocks.com/am/
    json/realms/root/realms/<realm>/authenticate?authIndexType=service&authIndexValue=PasswordGrant' \ (1)
    --header 'Content-Type: application/json' \
    --header 'Accept-API-Version: resource=2.1, protocol=1.0' \
    --data-raw '{
        "authId": "<auth-id>", (2)
        "callbacks": [
            {
                "type": "NameCallback",
                "output": [
                    {
                        "name": "prompt",
                        "value": "User Name"
                    }
                ],
                "input": [
                    {
                        "name": "IDToken1",
                        "value": "<end-user-username>" (3)
                    }
                ],
                "_id": 0
            },
            {
                "type": "PasswordCallback",
                "output": [
                    {
                        "name": "prompt",
                        "value": "Password"
                    }
                ],
                "input": [
                    {
                        "name": "IDToken2",
                        "value": "<end-user-password>" (4)
                    }
                ],
                "_id": 1
            }
        ]
    }'
    1 Replace <realm> with the realm where you want to authenticate the end user.
    2 Replace <auth-id> with authID from the response in the previous step
    3 Replace <end-user-username> with an end user username
    4 Replace <end-user-password> with an end user password
  4. View the response to see the session token, represented as tokenID:

    Show response
    {
        "tokenId": "iqY2oQpz_6LgFrXa449JtLUtKXo.*AAJTSQACMDIAAlNLABx4c1JzVEdTN2l5ZVhzeWhtcTBzcXBrV1hZYkE9AAR0eXBlAANDVFMAAlMxAAIwMQ..*",
        "successUrl": "/enduser/?realm=/alpha", (1)
        "realm": "/alpha" (1)
    }
    1 The example response is from an Alpha realm request.

Use an end-user session token

To use the session token with the REST API, set it as an HTTP header value. For the HTTP header field name, use the tenant session cookie name (found in Tenant Settings > Global Settings > Cookie).

The following example uses the session token to get information about the session:

Show request
curl \
--request POST 'https://<tenant-name>.forgeblocks.com/am/
json/realms/root/realms/<realm>/sessions?_prettyPrint=true&_action=getsessioninfo' \ (1)
--header 'Accept-API-Version: resource=4.0' \
--header 'Content-Type: application/json' \
--header '<session-cookie-name>: <session-cookie>' \ (2) (3)
--data-raw ''
1 Replace <realm> with the realm where you want to authenticate the end user.
2 Replace <session-cookie-name> with the session cookie name configured for the tenant.
3 Replace <session-token> with the tokenId in the authentication response (see Get an end-user session token).
Show response
{
    "username": "ed88fc9d-2f43-4cdd-af06-403bde5cf56c",
    "universalId": "id=ed88fc9d-2f43-4cdd-af06-403bde5cf56c,ou=user,o=alpha,ou=services,ou=am-config", (1)
    "realm": "/alpha", (1)
    "latestAccessTime": "2021-07-30T18:36:02Z",
    "maxIdleExpirationTime": "2021-07-30T19:06:02Z",
    "maxSessionExpirationTime": "2021-07-30T20:36:01Z",
    "properties": {
        "AMCtxId": "1010cfb1-710a-42d2-9045-9a5672ff6d8f-105170",
        "mySessionProperty": ""
    }
}
1 The example response is from an Alpha realm request.

Authenticate to Identity Cloud REST API with Access Token

Overview

You will need an access token to authenticate to the following Identity Cloud REST API endpoints:

  • /openidm/*

  • /.well-known/*

  • /variables, /secrets, /restart (ESV endpoints)

The access token must include:

  • IDM admin privileges

  • An appropriate scope (for example, fr:idm:* or fr:idc:esv:*).

The /openidm/* endpoint exposes many, but not all, of the IDM APIs to Identity Cloud. For an expanded list of endpoints, see IDM REST API Endpoints.

Get an access token

The following examples use a Resource Owner Password Credentials (ROPC) grant flow. This flow lets the client use the resource owner’s username and password to get an access token.

Since the resource owner shares their credentials with the client, this flow is deemed the most insecure of the OAuth 2.0 flows. The resource owner’s credentials can potentially be leaked or abused by the client application, and the resource owner has no control over the authorization process.

You should implement the ROPC grant flow only if the resource owner has a trust relationship with the client (such as the device operating system, or a highly privileged application).

See OAuth 2.0 Grant Flows for more information on the grant flows available in Identity Cloud.

  1. Create an administrative OAuth2.0 client using either the REST API or the Identity Cloud Admin UI:

  2. Create a user identity in the Identity Cloud Admin UI with authorization role openidm-admin. See Create a user identity with openidm-admin authorization role.

  3. Create an access token using an OAuth 2.0 authorization grant flow. The grant flow needs to specify the credentials of the OAuth 2.0 client (step 1) and the realm user identity (step 2):

    Show request
    $ curl \
    --request POST 'https://<tenant-name>.forgeblocks.com/am/
    oauth2/realms/root/realms/<realm>/access_token?auth_chain=PasswordGrant' \ (1)
    --header 'Content-Type: application/x-www-form-urlencoded' \
    --data-urlencode 'grant_type=password' \ (2)
    --data-urlencode 'username=<realm-user-identity-username>' \ (3)
    --data-urlencode 'password=<realm-user-identity-password>' \ (4)
    --data-urlencode 'scope=fr:idm:*' \
    --data-urlencode 'client_id=<oauth2-client-name>' \ (5)
    --data-urlencode 'client_secret=<oauth2-client-password>' (6)
    1 Replace <realm> with the realm where you want to create the access token.
    2 Note grant type password which represents Resource Owner Password Credentials Grant.
    3 Replace <realm-user-identity-username> with the username you have chosen for the realm user with IDM admin authorization.
    4 Replace <realm-user-identity-password> with the password you have chosen for the realm user with IDM admin authorization.
    5 Replace <oauth2-client-name> with the name that you have chosen for the OAuth 2.0 client.
    6 Replace <oauth2-client-password> with the password that you have chosen for the OAuth 2.0 client.
  4. View the response to see the access token, represented as access_token:

    Show response
    {
        "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9... ...8ECmkyDJKow8Qp_Tnp_lGNRJzLWi18iUGQrCTtxyTXw",
        "scope": "fr:idm:*",
        "token_type": "Bearer",
        "expires_in": 3598
    }

Use an access token

To use the access token with the REST API, set it as a bearer token in the Authorization HTTP header for each API request.

The following example uses the access token to get a list of identities:

Show request
$ curl \
  --request GET 'https://<tenant-name>.forgeblocks.com/openidm/
managed/<realm>_user?_fields=userName,givenName,sn,mail,accountStatus&_prettyPrint=true&_queryFilter=true' \ (1)
  --header 'authorization: Bearer <access-token>' (2)
1 Replace <realm> with the realm where you created the access token.
2 Replace <access-token> with the access_token in the authentication response (see Get an access token).
Show response
{
    "result": [
        {
            "_id": "f413db4c-cebd-4950-81e6-57bdb47921a4",
            "_rev": "0000000016e6754b",
            "userName": "exampleuser",
            "accountStatus": "active",
            "givenName": "Example",
            "sn": "User",
            "mail": "exampleuser@example.com"
        },
        {
            "_id": "15249a65-8f9a-4063-9586-a2465963cee4",
            "_rev": "0000000016e6754b",
            "userName": "exampleuser2",
            "accountStatus": "active",
            "givenName": "Example",
            "sn": "User",
            "mail": "exampleuser2@example.com"
        },
        {
            "_id": "30485bc4-fdbb-4946-8ce4-1a53c6824d92",
            "_rev": "0000000016e6754b",
            "userName": "exampleuser3",
            "accountStatus": "active",
            "givenName": "Example",
            "sn": "User",
            "mail": "exampleuser3@example.com"
        }
    ],
    "resultCount": 3,
    "pagedResultsCookie": null,
    "totalPagedResultsPolicy": "NONE",
    "totalPagedResults": -1,
    "remainingPagedResults": -1
}

Create an administrative OAuth 2.0 client using REST API

  1. Create a session token by authenticating an Identity Cloud tenant administrator username and password. See Get a tenant administrator session token.

  2. Use the session token to create an administrative OAuth 2.0 client with scope fr:idm:*:

    Show request with abridged body
    $ curl \
    --request PUT 'https://<tenant-name>.forgeblocks.com/am/
    json/realms/root/realms/<realm>/realm-config/agents/OAuth2Client/<oauth2-client-name>' \ (1) (2)
    --header 'accept: application/json' \
    --header 'Content-Type: application/json' \
    --header '<session-cookie-name>: <session-token>' \ (3) (4)
    --data-raw '{
      "coreOAuth2ClientConfig": {
        ...
        "userpassword": "<oauth2-client-password>", (5)
        "clientType": {
          "inherited": false,
          "value": "Confidential"
        },
        ...
        "scopes": {
          "inherited": false,
          "value": [
            "fr:idm:*" (6)
          ]
        },
        ...
      },
      "advancedOAuth2ClientConfig": {
        ...
        "grantTypes": {
          "inherited": false,
          "value": [
            "password" (7)
          ]
        },
        ...
      },
      ...
    }'
    1 Replace <realm> with the realm where you want to create the OAuth 2.0 client.
    2 Replace <oauth2-client-name> with the name that you have chosen for the OAuth 2.0 client.
    3 Replace <session-cookie-name> with the session cookie name configured for the tenant.
    4 Replace <session-token> with the tokenId in the authentication response (see Get a tenant administrator session token).
    5 Replace <oauth2-client-password> with the password that you have chosen for the OAuth 2.0 client.
    6 Note scope fr:idm:* which lets the client grant access to managed identities.
    7 Note grant type password which represents Resource Owner Password Credentials Grant.
    Show request with full body
    $ curl \
    --request PUT 'https://<tenant-name>.forgeblocks.com/am/json/realms/root/realms/<realm>/realm-config/agents/OAuth2Client/<oauth2-client-name>' \
    --header 'accept: application/json' \
    --header 'Content-Type: application/json' \
    --header '<session-cookie-name>: <session-token>' \
    --data-raw '{
      "coreOAuth2ClientConfig": {
        "agentgroup": "",
        "status": {
          "inherited": false,
          "value": "Active"
        },
        "userpassword": "<oauth2-client-password>",
        "clientType": {
          "inherited": false,
          "value": "Confidential"
        },
        "loopbackInterfaceRedirection": {
          "inherited": true,
          "value": true
        },
        "redirectionUris": {
          "inherited": false,
          "value": [
            "https://httpbin.org/anything"
          ]
        },
        "scopes": {
          "inherited": false,
          "value": [
            "fr:idm:*"
          ]
        },
        "defaultScopes": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        },
        "clientName": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        },
        "authorizationCodeLifetime": {
          "inherited": true,
          "value": 0
        },
        "refreshTokenLifetime": {
          "inherited": true,
          "value": 0
        },
        "accessTokenLifetime": {
          "inherited": true,
          "value": 0
        }
      },
      "advancedOAuth2ClientConfig": {
        "name": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        },
        "descriptions": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        },
        "requestUris": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        },
        "responseTypes": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        },
        "grantTypes": {
          "inherited": false,
          "value": [
            "password"
          ]
        },
        "contacts": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        },
        "tokenEndpointAuthMethod": {
          "inherited": true,
          "value": "string"
        },
        "sectorIdentifierUri": {
          "inherited": true,
          "value": "string"
        },
        "subjectType": {
          "inherited": true,
          "value": "string"
        },
        "updateAccessToken": {
          "inherited": true,
          "value": "string"
        },
        "clientUri": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        },
        "logoUri": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        },
        "policyUri": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        },
        "isConsentImplied": {
          "inherited": true,
          "value": true
        },
        "mixUpMitigation": {
          "inherited": true,
          "value": true
        }
      },
      "coreOpenIDClientConfig": {
        "claims": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        },
        "postLogoutRedirectUri": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        },
        "clientSessionUri": {
          "inherited": true,
          "value": "string"
        },
        "defaultMaxAge": {
          "inherited": true,
          "value": 0
        },
        "defaultMaxAgeEnabled": {
          "inherited": true,
          "value": true
        },
        "defaultAcrValues": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        },
        "jwtTokenLifetime": {
          "inherited": true,
          "value": 0
        }
      },
      "signEncOAuth2ClientConfig": {
        "jwksUri": {
          "inherited": true,
          "value": "string"
        },
        "jwksCacheTimeout": {
          "inherited": true,
          "value": 0
        },
        "jwkStoreCacheMissCacheTime": {
          "inherited": true,
          "value": 0
        },
        "tokenEndpointAuthSigningAlgorithm": {
          "inherited": true,
          "value": "string"
        },
        "jwkSet": {
          "inherited": true,
          "value": "string"
        },
        "idTokenSignedResponseAlg": {
          "inherited": true,
          "value": "string"
        },
        "idTokenEncryptionEnabled": {
          "inherited": true,
          "value": true
        },
        "idTokenEncryptionAlgorithm": {
          "inherited": true,
          "value": "string"
        },
        "idTokenEncryptionMethod": {
          "inherited": true,
          "value": "string"
        },
        "idTokenPublicEncryptionKey": {
          "inherited": true,
          "value": "string"
        },
        "clientJwtPublicKey": {
          "inherited": true,
          "value": "string"
        },
        "mTLSTrustedCert": {
          "inherited": true,
          "value": "string"
        },
        "mTLSSubjectDN": {
          "inherited": true,
          "value": "string"
        },
        "mTLSCertificateBoundAccessTokens": {
          "inherited": true,
          "value": true
        },
        "publicKeyLocation": {
          "inherited": true,
          "value": "string"
        },
        "userinfoResponseFormat": {
          "inherited": true,
          "value": "string"
        },
        "userinfoSignedResponseAlg": {
          "inherited": true,
          "value": "string"
        },
        "userinfoEncryptedResponseAlg": {
          "inherited": true,
          "value": "string"
        },
        "userinfoEncryptedResponseEncryptionAlgorithm": {
          "inherited": true,
          "value": "string"
        },
        "requestParameterSignedAlg": {
          "inherited": true,
          "value": "string"
        },
        "requestParameterEncryptedAlg": {
          "inherited": true,
          "value": "string"
        },
        "requestParameterEncryptedEncryptionAlgorithm": {
          "inherited": true,
          "value": "string"
        },
        "tokenIntrospectionResponseFormat": {
          "inherited": true,
          "value": "string"
        },
        "tokenIntrospectionSignedResponseAlg": {
          "inherited": true,
          "value": "string"
        },
        "tokenIntrospectionEncryptedResponseAlg": {
          "inherited": true,
          "value": "string"
        },
        "tokenIntrospectionEncryptedResponseEncryptionAlgorithm": {
          "inherited": true,
          "value": "string"
        }
      },
      "coreUmaClientConfig": {
        "claimsRedirectionUris": {
          "inherited": true,
          "value": [
            "Unknown Type: any"
          ]
        }
      }
    }'
    Show response
    {
        "_id": "<oauth2-client-name>",
        "_rev": "1881599229",
        "coreOAuth2ClientConfig": {
            "agentgroup": null,
            "userpassword": null,
            "userpassword-encrypted": "AAAAA0FFUwIQySwvWyQsAjcFmGkkCz/irQfToaS98EKCAfPfemvgl9cTtaL09rFoUg==",
            "scopes": {
                "inherited": false,
                "value": [
                    "fr:idm:*"
                ]
            },
            "clientType": {
                "inherited": false,
                "value": "Public"
            },
            "redirectionUris": {
                "inherited": false,
                "value": [
                    "https://httpbin.org/anything"
                ]
            },
            "status": {
                "inherited": false,
                "value": "Active"
            }
        },
        "advancedOAuth2ClientConfig": {
            "grantTypes": {
                "inherited": false,
                "value": [
                    "password"
                ]
            }
        },
        "_type": {
            "_id": "OAuth2Client",
            "name": "OAuth2 Clients",
            "collection": true
        }
    }

Create an administrative OAuth 2.0 client using Identity Cloud Admin UI

  1. Using the realm menu, navigate to the realm where you want to create the OAuth 2.0 client.

  2. Follow the steps in Register an application or service:

    1. In step 2, choose an app type of Service / Machine-to-machine.

  3. Follow the steps in Create a client profile.

    1. In step 4, enter the following:

      Grant Types

      Resource Owner Password Credentials

      Scopes

      fr:idm:*

    2. Skip the Advanced Settings in step 5.

Create a user identity with openidm-admin authorization role

  1. Using the realm menu, navigate to the realm where you want to create the user identity.

  2. Go to Identities > Manage > Users, and then click + New User.

  3. Enter a user name.

  4. Complete the remaining fields, and then click Save.

  5. On the Manage Identities page, click the user you just created.

  6. Click Reset Password, then enter a new password.

    Make sure that you use a strong password.

  7. Select Authorization Roles, and then click Add Authorization Roles.

  8. Add the openidm-admin role, and then click Save.

Identity Cloud Postman Collection

Overview

Identity Cloud provides REST APIs to help you manage identities, authenticate to the system, monitor Identity Cloud, and more.

You can also use the AM APIs and IDM APIs with Identity Cloud.

To help you quickly use and understand these REST APIs, Identity Cloud provides a Postman collection, containing example requests grouped into features.

Features included:
 
・Intelligent Access
・User Self-Service
・Session Management
・Identity Profiles
・Managed Identities
・Auditing/Monitoring
・OAuth 2.0 Flows

postman collection overview

Getting started

  1. Download and install Postman.

  2. Download the Identity Cloud Postman collection.

  3. In Postman:

    1. Go to File > Import…​ > Upload Files.

    2. Browse to the collection JSON file you downloaded in the previous step, and then click Open.

    3. Click Import to bring the collection into your workspace.

Preparing your Identity Cloud

To use the Identity Cloud Postman collection, you must create a user identity in Identity Cloud that the collection requests can connect to.

  1. Log in to the Identity Cloud as a tenant administrator.

  2. Ensure you are managing the Alpha realm.

    1. If not, select the current realm in the top-left corner, click Switch realm…​, and switch to the Alpha realm.

  3. Go to Identities > Manage > Users, and then click + New User.

  4. Enter the user name as "postmanAdminUser".

  5. Complete the remaining fields, and then click Save.

  6. On the Manage Identities page, click the user you just created.

  7. Click Reset Password, then enter a new password.

    Make sure that you use a strong password.

  8. Select Authorization Roles, and then click Add Authorization Roles.

  9. Add the openidm-admin and openidm-authorized roles, and then click Save.

The collection requests for managed users will authenticate to Identity Cloud using these credentials.

Proceed to the next section to learn how to enter these credentials, plus other settings necessary to use the collection.

Configuring the collection

The Identity Cloud Postman collection uses a number of variables to populate the requests. These variables are stored at collection level. To view them, click on the top level of the collection menu (labelled "ForgeRock Identity Cloud Collection"), then select the Variables tab.

postman collection variables

The variables are initially set with placeholder values that you will need to modify or replace. For example, the collection needs to know the Identity Cloud URL, as well as your admin access credentials.

To edit the variables, enter new values in the INITIAL VALUE column. Then click Save to make the edits permanent.

See Required variable values to understand which variables you need to edit before you can use the collection. See Optional variable values to understand which variables you may want to edit to customize the collection to suit your environment.

You can then start using the collection.

You can also override the default collection-level variables by creating a Postman Environment. Use the same variable names as those in the table above.

For information on creating a Postman Environment, see Managing environments in the "Postman Learning Center".

Required variable values

Before using the collection, you must provide the following variable values:

Make sure that you use strong passwords for access credentials.

Variable Default Description

platformUrl

https://<tenant-name>.forgeblocks.com

Specifies the root URL of your Identity Cloud.

amUrl

https://<tenant-name>.forgeblocks.com/am

Specifies the URL of the Access Management (AM) component of your Identity Cloud.

idmUrl

https://<tenant-name>.forgeblocks.com/openidm

Specifies the URL of the Identity Management (IDM) component of your Identity Cloud.

IDCloudAdminUsername

admin@example.com

Specifies the username of an Identity Cloud adminstrator who can authenticate to the top-level realm, and create OAuth 2.0 clients and managed users.

IDCloudAdminPassword

Not Set

Specifies the password of the Identity Cloud adminstrator above.

postmanClientSecret

Not Set

Specifies the password to be used by the OAuth 2.0 administrative, private, and public clients.

These clients are created when you run the Prerequisite requests from the collection.

postmanAdminPassword

Not Set

Specifies the password to be used by the OAuth 2.0 managed admin user.

This is the password you set up in Preparing your Identity Cloud.

postmanDemoPassword

Not Set

Specifies the password to be used by OAuth 2.0 managed realm user.

The realm user is created when you run the Prerequisite requests from the collection.

logApiKey

Not Set

Specifies the API key used to access the monitoring endpoints. It is used in the auditing and monitoring collection requests only.

See Obtaining API Credentials.

logApiSecret

Not Set

Specifies the API secret used to access the monitoring endpoints. It is used in the auditing and monitoring collection requests only.

See Obtaining API Credentials.

Optional variable values

The collection uses the following additional variables, which will work using their default values, although you may want to modify them later:

Variable Default Description

realm

/realms/root/realms/alpha

Specifies the realm that the majority of the requests in the collection target.

You must specify the entire hierarchy of the realm, starting at the top-level realm.

Prefix each realm in the hierarchy with the realms keyword.
Example: "/realms/root/realms/customers/realms/europe".

customDomainUrl

https://id.mycompany.com

Specifies a custom domain that can be used for domain specific requests such as "/.well-known/assetlinks.json".

cookieName

iPlanetDirectoryPro

Specifies the name of the session cookie for AM sessions.

Change the default variable value as a security best practice.

loginJourney

Login

Specifies the authorization journey name to use.

See Login.

redirect_uri

https://httpbin.org/anything

Specifies the URI to which the OAuth 2.0 client will redirect the user upon a successful authentication request.

postmanAdminClientId

postmanAdminClient

Specifies the username to be used for the OAuth 2.0 administrative client.

postmanConfidentialClientId

postmanConfidentialClient

Specifies the username to be used for the OAuth 2.0 private client.

postmanPublicClientId

postmanPublicClient

Specifies the username to be used for the OAuth 2.0 public client.

postmanAdminUsername

postmanAdminUser

Specifies the username to be used for the OAuth 2.0 managed admin user

This is the username you set up in Preparing your Identity Cloud.

postmanDemoUsername

postmanDemoUser

Specifies the username to be used for the OAuth 2.0 managed realm user.

postmanDemoEmail

demo.user@postman.example.com

Specifies the email to be used for the OAuth 2.0 managed realm user.

Using the collection

Before using the Identity Cloud Postman collection, you should run the Prerequisite requests. The requests configure your Identity Cloud with the necessary elements, such as OAuth 2.0 clients and managed users

Running the prerequisite requests

Ensure you have configured the required collection variables as described in Configuring the collection before running the prerequisite requests.
  1. In Postman, with the Identity Cloud collection loaded, open the Prerequisites section.

  2. Select the first request in the list, examine the details, and when you’re satisfied the request is properly formed, click the Send button.

    Many of the requests have associated tests; for example, that the response code was 200. Postman displays the test results alongside the response to the request.

    Many of the requests will set a global variable containing a value returned in the response, for use in subsequent requests.

    The details of these can be seen in the Tests tab of a request. You can also view the values of these global variables by clicking Environment Quick Look ().

  3. Repeat the previous step for each request in the Prerequisites folder.

When completed, Identity Cloud will contain the following:

  • Three OAuth 2.0 clients:

    1. A client named postmanAdminClient, which provides an access token that can be used to administer the Alpha realm.

    2. A client named postmanConfidentialClient, which is used by the OAuth 2.0 requests to demonstrate a number of grant flows.

    3. A client named postmanPublicClient, which is used by the OAuth 2.0 requests to demonstrate a number of grant flows.

  • Two "alpha_user" identities:

    1. A postmanAdminUser identity, which connects to the postmanAdminClient in order to perform realm administration requests.

    2. A postmanDemoUser identity, which demonstrates a number of user-related endpoints, such as identity profiles, and user self-service.

If you need to recreate any of the above, or decide to alter the default values, run each of the steps in the Prerequisite folder again.

Running the requests

The requests in the collection are split into different features. To run the calls for a feature, open the relevant folder, and run each request in sequence.

Note that intelligent access and identity profiles have additional functionality. See each section for details.

Intelligent access

There are scripts in the Intelligent Access requests that attempt to detect the callbacks that the first step returns, and sets the next request to handle it.

To view the details of this script:

  1. Click on the top level of the collection menu (labelled "ForgeRock Identity Cloud Collection"), then select the Pre-request Scripts tab.

  2. Within the tab, examine the detectCallbacks script.

When manually running through the steps, examine the response returned in the first call, and run the relevant next step. The collection is able to handle the following ready-to-use callbacks:

Table 1. Intelligent Access Callback Steps
Step Callback

Step 2a

Username and password callbacks, together in a page node.

Step 2b

Validated create username and password callbacks, together in a page node.

Step 2c

Choice callbacks.

Step 2d

Text input callbacks.

Step 2e

Device profile callbacks. See Configure Device Profiling.

Step 2f

Progressive profile callbacks.

Identity profiles

Some endpoints require the ID of an identity, rather than the username.

An example of this is when getting the OAuth 2.0 profiles a user has provided consent to.

When running the Identity Profiles requests, ensure you have also executed the request named "Step 3. Get Users' ID".

The result is stored in the demoUserId global variable.

Overview

To help you integrate your Android apps with Identity Cloud, you can upload an Android assetlinks.json to your Identity Cloud environment. The assetlinks.json file lets your website declare an association with your Android apps.

To upload the file, use the the /.well-known/assetlinks.json endpoint in the REST API. The endpoint is accessed using a custom domain.

Make sure that you have already set up a custom domain for each environment and realm where you need to upload an Android assetlinks.json file.
  1. Create an access token for the realm that is using the custom domain. See Get an access token.

  2. Upload or replace the assetlinks.json file:

    Show request
    curl \
    --request PUT '<custom-domain-url>/.well-known/assetlinks.json' \ (1)
    --header 'Authorization: Bearer <access_token>' \ (2)
    --header 'Content-Type: application/json' \
    --data-raw '[ (3)
      {
        "relation": [
          "delegate_permission/common.handle_all_urls",
          "delegate_permission/common.get_login_creds"
        ],
        "target": {
          "namespace": "web",
          "site": "https://id.mycompany.com"
        }
      }
    ]'
    1 Replace <custom-domain-url> with your custom domain, for example id.mycompany.com.
    2 Replace <access-token> with the access token.
    3 Replace the example assetlinks.json JSON content with your own JSON content.
    Show response
    [
        {
            "relation": [
                "delegate_permission/common.handle_all_urls",
                "delegate_permission/common.get_login_creds"
            ],
            "target": {
                "namespace": "web",
                "site": "https://id.mycompany.com"
            }
        }
    ]
An access token is not needed to to view the assetlinks.json file as it is publicly accessible.
  1. View the assetlinks.json file using a GET request:

    Show request
    curl \
    --request GET '<custom-domain-url>/.well-known/assetlinks.json'
    Show response
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "web",
            "site": "https://id.mycompany.com"
        }
    }
  1. Create an access token for the realm that is using the custom domain. See Get an access token.

  2. Delete the assetlinks.json file:

    Show request
    curl \
    --request DELETE '<custom-domain-url>/.well-known/assetlinks.json' \ (1)
    --header 'Authorization: Bearer <access_token>' \ (2)
    1 Replace <custom-domain-url> with your custom domain, for example id.mycompany.com.
    2 Replace <access-token> with the access token.
    Show response
    [
        {
            "relation": [
                "delegate_permission/common.handle_all_urls",
                "delegate_permission/common.get_login_creds"
            ],
            "target": {
                "namespace": "web",
                "site": "https://id.mycompany.com"
            }
        }
    ]

Identity Cloud Deep Dives

Selected pages from across all ForgeRock Product Documentation

icon am Access Management

Provides infrastructure for managing users, roles, and access to protected resources.

Intelligent Authentication
•   Authentication Nodes and Trees
•   Multi-Factor and Strong Authentication
•   Web Agents and Java Agents for SSO
•   Mobile Authenticator

Authorization
•   Entitlement Policies
•   Web Agents and Java Agents for Enforcement
•   Transactional Authorization
•   OAuth 2.0 Dynamic Scopes

Federation
•   SAML 2.0 IDP and SPs
•   SAML 2.0 SSO and SLO
•   Active Directory Federation Services (ADFS)
•   SAML 2.0 Attribute and Advanced Profiles

 
•   OpenID Connect
•   OAuth 2.0
•   Social Login
•   OAuth 2.0 Dynamic Scopes

icon idm Identity Management

Reconciles customer identity data to ensure accurate information across disparate resources within an organization.

Identity Synchronization
•   Discovery and Synchronization
•   Reconciliation
•   Password Synchronization
•   Directory Services and Active Directory Plugins
•   Supported Connectors

User Self-Service
•   Registration
•   Password Reset
•   Knowledge-Based Authentication
•   Forgotten Username
•   Progressive Profile Completion
•   Profile and Privacy Management Dashboard
•   Consent and Preference Management
•   Terms and Conditions Versioning

Identity Lifecycle and Relationships
•   Inbound Provisioning Engine
•   Managed Objects
•   Relationship Lifecycle Management
•   Role Lifecycle Management
•   Entitlement Lifecycle Management

Social Identity
•   Registration
•   Authorization
•   Account Linking
•   Attribute Scope Management

20 Edge Security

Integrates web applications, APIs, microservices, Internet of Things devices, and cloud-based services with the ForgeRock Identity Platform.

Identity Gateway
•   Studio
•   Single Sign-On
•   Password Replay
•   Login Credentials From AM
•   Policy Enforcement
•   Hardening Authorization
•   Certificate-Bound Access Tokens
•   Finance APIs
•   WebSocket Protocol

 

•   Throttling
•   UMA Resource Server
•   DevOps Tooling
 
Federation
•   OpenID Connect 1.0
•   OAuth 2.0
•   SAML 2.0
•   SAML resources for mobile applications

Microservices Security
•   Microgateway

 
•   Token Validation Microservice

Beyond Identity Cloud Docs

Useful IAM information beyond the scope of Identity Cloud Docs

Knowledge Base Articles

•   Identity Cloud

•   Access Management

•   Identity Management

•   Directory Services

•   ForgeRock SDKs

Staff Picks

•   ForgeRock Identity Cloud as a SAML 2.0 Identity Provider

•   Troubleshooting ForgeRock Platform Integration

•   Notes on Scripting in AM 7.0

•   Configuring CORS Support

•   Searchable, single-page Identity Cloud Docs

Text Tutorials
From the ForgeRock SDKs:
•   Intercept and Modify REST Calls

•   Perform Transactional Authorization

•   Detect Device Tampering

2-minute Video Explainers

•   Access Management

•   Identity Management

•   Directory Services

•   Edge Security

•   Identity Gateway

ForgeRock Community Forums

•   Access Management

•   Directory Services

•   Identity Management

ForgeRock Blogs

•   ForgeRock Community Blog

•   ForgeRock Corporate Blog

Identity Cloud How-Tos

Your Tenant

•   Monitor uptime status

•   Monitor system performance

•   View tenant settings

•   View audit logs

•   Edit your tenant administrator profile

•   Manage tenant administrator 2-step verification (MFA)

•   Invite tenant administrators

•   Activate/deactivate/delete tenant administrators

•   Configure a realm

•   Override realm authentication attributes

•   Switch realms

•   Create a custom domain name

•   Customize the end-user UI theme

•   Promote configuration changes

Applications

•   Determine your application type

•   Register an application or service

•   Configure CORS Support

•   Create a client profile

•   Manage password policy

•   Integrate policy agents

•   Test SAML2 SSO using JSP flows
 

Connections  

•   Connect to an identity resource server

•   Create a connector configuration over REST

•   Bulk import identities

Identities

•   Manage organizations

•   Create a user profile

•   Edit a user profile

•   Reset a user password

•   End a user session

•   Create an external role

•   Create an internal role

•   Create an assignment

•   Edit an assignment

•   Bulk import identities

•   Optimize identity search
 

Email Templates  

•   Default email templates

•   Configure your own email service provider

•   Customize an email template

•   Create a new email template

Journeys

•   Create a login journey

•   Deactivate the end-user profile page

•   Configure device profile authentication

•   Create a registration journey

•   Create a progressive password journey

•   Create an update password journey

•   Create a reset password journey

•   Create a forgotten username journey

•   Create a custom journey

•   Set the default end-user journey
 

Policy  

•   Configure a password policy

FAQs

•    How do I get the organization model in my Identity Cloud environment?

•    How do I create and manage scripts?

•    How do I securely transfer secrets?

•    How do find IDM & AM user properties?

•    How do I configure CORS Support?

•    Where can I find the allow-list IP addresses Identity Cloud uses?

•    How do I search in only Identity Cloud Docs?

Support

•   Submit a Support ticket

•   Access Support Services

•   Promote configuration changes

Supported Browsers

Browser Version

Google Chrome and Chromium

Latest stable version

Firefox

Latest stable version

Safari

Latest stable version

Internet Explorer

11 and later

While ForgeRock Identity Cloud works with all supported browsers, administrative activity works best using Google Chrome.

Click here for legal information about product documentation published by ForgeRock.

About ForgeRock Identity Platform software

ForgeRock Identity Platform serves as the basis for our simple and comprehensive identity and access management solution. We help our customers deepen their relationships with their customers, and improve the productivity and connectivity of their employees and partners. For more information about ForgeRock and about the platform, see https://www.forgerock.com.

The platform includes the following components:

  • ForgeRock® Access Management (AM)

  • ForgeRock® Identity Management (IDM)

  • ForgeRock® Directory Services (DS)

  • ForgeRock® Identity Gateway (IG)

Third-party copyrights

FontAwesome

Copyright © 2017 by Dave Gandy, https://fontawesome.com/. This Font Software is licensed under the SIL Open Font License, Version 1.1. See https://opensource.org/licenses/OFL-1.1.

Security & Compliance

Overview

The ForgeRock Identity Cloud provides full tenant isolation in a multi-tenant cloud service by using individual trust zones. Every customer’s 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.

Certifications & compliance

  • Find our ISO 27001 certificate in the Schellman Certificate Directory.

    • To view the certificate, go to the Shellman certificate directory, and then search for ForgeRock.

    • To download the ForgeRock certificate, click this link: https://zpr.io/RUTE2.
      The direct link to the certificate is obsolete when a newer version becomes available. If the direct link doesn’t work, then use the main certificate directory search.

  • See our CSA CIAQ certification.

  • See how ForgeRock supports HIPAA compliance.

  • See how ForgeRock can help with GDPR.

Security white paper

Learn more about our security practices in our security white paper.

Identity Cloud Product Lifecycle and Releases

ForgeRock Identity Cloud releases new features, updates functionality and fixes bugs on a continual cadence. ForgeRock aims to deliver features and functionality that will be the most useful, complete and intuitive for customers. In order to deliver on this goal we have several stages to our release lifecycle.

Early access

Participating in Early Access programs allow customers to provide feedback and collaborate with ForgeRock in designing future capabilities in the product.

Select customers are invited to provide feedback on new features. Customers are encouraged to give feedback and have an active say in product direction; product management and customer success will work with you to gather feedback. Features may be unstable, changed in backward-incompatible ways, and are not guaranteed to be released. We will use all reasonable efforts to communicate breaking changes to customers participating in the program.

Beta

Beta features give customers advanced insights into up-and-coming product capabilities with extra time to prepare to adopt the feature and provide design feedback to the product team. Generally speaking, functionality is stable and meets security and quality expectations but please note that a beta feature is not officially supported for production use.

Upcoming features

Customers receive notifications of new and upcoming features at least a week in advance of a release. The notifications provide customers with high-level information on changes or new functionality.

General availability

Features are available for production use and are fully functional and supported.

Bug fixes and low impact changes

On an ongoing basis, ForgeRock will make bug fixes and low impact changes as necessary to the Identity Cloud platform. These types of fixes will be deployed as necessary. Customers can monitor these in the Changelog and subscribe to the RSS feed.

Deprecation and end of life

In order to maintain both security and quality in ForgeRock Identity Cloud, we periodically have to modify or remove functionality.

See the list of Deprecation Notices.

Deprecated features

A feature or behavior (or API endpoint) flagged for deprecation means it is no longer actively enhanced, and is minimally maintained. Tenants using the feature at the time of deprecation will continue to have access to the feature until it goes End of Life, at which point customers will no longer have access to the feature. We know deprecation disruptions are inconvenient, and as such we attempt to limit the frequency of deprecations and to pair them with alternative options and/or migration recommendations where available.

Deprecation notification

Deprecation information is posted to the ForgeRock Identity Cloud documentation. Deprecation notices typically include a date that the feature or behavior will be moved to End of Life. Our policy is to flag a feature for deprecation with at least twelve (12) months advance notice prior to End of Life whenever possible, in order to allow a twelve (12) month migration window.

Periodically, and in case of emergency (critical vulnerabilities or changes required by applicable law or third-party certification standards), we may accelerate this time frame. In such cases, we will provide as much prior notice as is reasonable under the circumstances.

During deprecation

Customers should engage in a migration to move away from the deprecated feature or behavior.

End of life

Features that reach the end of life stage are removed from the platform. Continued use of these features will likely result in errors.

Deprecation Notices

For information about the Identity Cloud product lifecycle and deprecation, see Deprecation and end of life.

ForgeRock Identity Cloud Email Server Service

Notification date

April 12, 2021

Built-in Email Server Service

ForgeRock no longer supports the default email provider settings for use in production. The default email provider settings will only be available for testing purposes. Current customers can continue to use the default email provider settings for production purposes, but this functionality will reach end of life on April 12, 2022. Customers should move to using their own email provider.
 

End of life date

April 12, 2022

Groovy OIDC Custom Claims Script

Notification date

April 20, 2021

ForgeRock will continue to support the Groovy version of the OIDC custom claims script until it is end of lifed on April 20th 2022. Current customers can continue to use the Groovy version of the OIDC custom claims script for production purposes, but this functionality will reach end of life on April 20, 2022.
 

End of life date

April 20, 2022

Changelog

See the Coming Soon page for information on upcoming releases.

Subscribe to get automatic updates: Changelog RSS feed

22 Dec 2021

Issue ID Summary

IAM-1757

Adding security question translation causes KbaCreateNode to loop

IAM-1792

Goto param in start over link is not URL encoded

17 Dec 2021

Issue ID Summary

FRAAS-4765

Tenant administrators should not have the option in the UI to delete or disable themselves

FRAAS-8290

Tenant administrator list needs to show if MFA is activated

FRAAS-8437

Admin UI encoding IDM system property specifiers in email templates

FRAAS-8584

Cannot apply dark theme on security question picker

FRAAS-8754

Display preview URL in the journey editor

IAM-1592

User is redirected to error page after trying to invite already invited admin

IAM-1621

Add security questions configuration to Admin UI

IAM-1685

WCAG 2.2 UI Compliance

IAM-1690

Remove ghost in Not Found page

IAM-1697

Theme transition flickering between journeys

IAM-1699

End user profile picture is not shown in top navigation bar

IAM-1716

Tenant administrator account details not loaded correctly after refresh

IAM-1739

Allow subsequent login attempts to enable next button

IAM-1740

Default provider setup should keep 'Use my own provider' toggled off

IAM-1753

Allow login theme to be set properly for URLs with both query parameters and route parameters

IAM-1765

Paging error on tenant administrator list

OPENAM-18511

Missing navigation options when an expired link from "Email Suspend" node is used

15 Dec 2021

Issue ID Summary

AME-21617

Create Scripted implementation for SAML2 IDP Attribute Mapper

AME-21303

Create Scripted implementation of ScopeValidator#additionalDataToReturnFromEndpoint methods

AME-21265

Scope Implementation Class per Client not just per Provider

AME-21262

OAuth2 Scripts per Client not just per Provider

OPENAM-18167

OIDC requests with request parameter fail with 500 error when there is no session using POST

OPENAM-18154

Wrong AMR returned with prompt=login and force authn setting enabled

OPENAM-18121

Slow loading in Authentication Tree

OPENAM-18120

Audit logging service does not correctly reflect the "prompt" URL parameter

OPENAM-18119

Audit log no longer shows the userID of session being invalidated by amadmin

OPENAM-18043

Device Match module not setting correct AuthLevel

OPENAM-17979

Backchannel authentication - auth_req_id can be used to obtain multiple access tokens

OPENAM-17968

Scripting engine breaks when you create script with empty name

OPENAM-17923

Retry Limit Decision Should Not Have User Involvement when Save Retry Limit to User is Disabled

OPENAM-17783

Language tag limited to 5 characters instead of 8

OPENAM-17826

Introspect endpoint returns a static value for "expires_in" when using client based tokens

OPENAM-17610

OTP Email Sender node does not allow to specify connect timeout and IO/read timeout for underlying transport.

OPENAM-17458

Enable access to hasResumedFromSuspend within a script

OPENAM-16560

OAuth2 scope validation using policy engine should be configurable per OAuth2 client

OPENAM-16149

Allow JWT bearer client authn unreasonable lifetime limit to be configurable

OPENAM-15877

Support for Google reCAPTCHA v3

OPENAM-15340

OAuth2 RT - Ability to obtain original custom claim when regenerate the token

OPENIDM-16677

Cannot retrieve entries from /recon endpoint when using DS as a repo if reconprogressstate size exceeds index limits

10 Dec 2021

22 Nov 2021

Issue ID Summary

FRAAS-4276

Social Provider Handler node should default to "Normalized Profile to Managed User" transformation script

FRAAS-6275

During registration the "Next" button should be greyed out until all mandatory fields are completed

FRAAS-7827

Hyperlinks cannot link to header elements in T&Cs

FRAAS-8288

Add ability to search for a journey by name

FRAAS-8317

Hard browser cache reset required when switching default theme in realm

FRAAS-8367

Platform UI doesn’t allow "from name" to be configured in email templates

FRAAS-8613

Social IDP CSS is overridden by themes

FRAAS-8683

Stage field not showing on page nodes when value set to "themeId=name" prior to the new theme selector UI enhancement

IAM-1548

Enduser UI not hiding side menu and nav bar

IAM-1644

Create multiple locales at same time when adding a new T&C

IAM-1650

Update Gateway and Agents page when in no data state

IAM-1652

Use journey name to set page title in Login UI

IAM-1689

Text from push authentication node cannot be overriden via config translation override

IAM-1695

Clicking column header with no sorting enabled throws error

IAM-1713

Hosted Pages tenant settings view has incorrect description

OPENAM-18511

Missing navigation options when an expired link from "Email Suspend" node is used

11 Nov 2021

Issue ID Summary

AME-21261

Allow configuring "Issue Refresh Token" at OAuth client level

AME-21263

Overridable Id_Token claims per client not just per provider

IAM-1074

Provide Javascript defaults for AM scripts in Identity Cloud

OPENAM-12995

Allow configuration of 'Custom Login URL Template' at client level

OPENAM-14159

OAuth2 token storage to be configured per client

OPENAM-15381

Allow configuring "Issue Refresh Tokens on Refreshing Access Tokens" per client

OPENAM-16418

Client auth using private_key_jwt fails with 500 if claim format is wrong

OPENAM-17185

Need ability to configure Remote Consent Service at the client level

OPENAM-17262

Subname claim inconsistences

OPENAM-17548

Can’t go back to login page after invoking Social Authentication Nodes

OPENAM-17663

Improve the error response code for "Failed to revoke access token"

OPENAM-17669

Ability to encrypt or sign access tokens based on client IDs

OPENAM-17773

The acr_values parameter is mandatory on CIBA bc-authorize endpoint

OPENAM-17782

Policy evaluation fails with 400 error when user does not exist

OPENAM-17784

Session timeouts (maximum session time, maximum idle timeout) set incorrectly if username is dynamically created in a tree.

OPENAM-17801

OIDC userinfo subname claim returns incorrect value

OPENAM-17813

Allow /userinfo endpoint to include 'aud' claim in response

OPENAM-17814

Auth Tree step-up fails if username case does not match

OPENAM-17863

Authorization code is not issued when nonce is not supplied when using OpenID Hybrid profile

OPENAM-17912

Account lockout count is not reset correctly

04 Nov 2021

Issue ID Summary

FRAAS-8502

Unable to set default theme to a theme not on the first page of themes in Hosted Pages

IAM-673

Identity tabs in Platform UI not correctly positioned on small screens

IAM-1495

Platform admin theme editor has confusing modal behaviour

IAM-1499

Add theming to Platform UI to control color of login card: background, input, text…​

IAM-1501

Add ability to configure theme on a page node in journey editor

IAM-1517

Terms and Conditions published version should just display rendered text

IAM-1529

Links from non authorized page do not redirect user

29 Oct 2021

Issue ID Summary

FRAAS-8497

Alt text is being stripped from Hosted Pages custom header

21 Oct 2021

Issue ID Summary

FRAAS-7669

Page unresponsive message shown in End User UI when an organisation admin selects the password reset button for an organisation user

FRAAS-7960

Terms and Conditions UI does not list the locales already created

FRAAS-8048

Applications created without status don’t show default active status

FRAAS-8050

Allow Platform Admin UI to display all application types

FRAAS-8089

Theme layout overlays login box in theme designer

FRAAS-8138

Discovery URI missing from OAuth client

IAM-1117

Display data from linked systems when editing a user in Platform Admin UI

IAM-1204

Journey editor lines too light

IAM-1495

Platform admin theme editor has confusing modal behaviour

IAM-1498

Add font family dropdown to theme editor

IAM-1525

Application URL text is curtailed

12 Oct 2021

Issue ID Summary

IAM-1435

Add ability to create Java/Web Agents in Platform Admin UI

IAM-1613

Allow configuration and display of password policy where at least 1–4 of 4 character sets are required

06 Oct 2021

Issue ID Summary

AME-21058

Roll the config option for signing Request Object and Private Key JWT into one

AME-21411

Create an IDM passthrough authentication node

OPENAM-17405

Token introspection response not spec compliant

OPENAM-17515

Sub attribute in access token can be in wrong casing

OPENAM-17591

Session quota destroy next expiring action can fail when two new sessions attempt to read and update the same expiring session

OPENAM-17595

Calling endSession endpoint should fail gracefully instead of Unknown JWT error

OPENAM-17666

Update Scripted Decision Node bindings to deprecate "sharedState" and "transientState" and add new "state"

OPENAM-17683

Selfservice user registration auto login fails for a sub-realm

OPENAM-17828

Apostrophe in username breaks Push/OATH device registration

OPENAM-18233

Social Provider Configuration for Google (Native iOS) does not work without a client secret

OPENDJ-8178

Change of data format in date fields: trailing zeros on milliseconds are now truncated

OPENIDM-15951

Support additional mime types for CSV bulk import

OPENIDM-16081

Prevent users saving managed objects with invalid names

OPENIDM-16089

Enhance error message for failed config property substitution in email templates

OPENIDM-16473

Task scanner job fails on null top level objects

29 Sep 2021

Issue ID Summary

FRAAS-8110

Spinning wheel displayed when using an expired link from email suspend node

FRAAS-8133

Login UI flashes with ForgeRock logo before loading the End User UI

IAM-1398

Accessing platform UI with old token redirects user

22 Sep 2021

Issue ID Summary

FRAAS-5860

Table markup issue in email templates

IAM-1409

Password Policy on Self-Service Registration page does not reset when blanking entered text

IAM-1544

Platform UI allows creating scripts without any name

IAM-1558

Assignment console errors caused by deleted managed object mapping

IAM-1576

Cannot delete email template from preview page

IAM-1577

Styles not being shown on edit email template page

15 Sep 2021

Issue ID Summary

IAM-1150

Remove data table component in favor of adding cell specific components

IAM-1547

End-User Password Update changes session cookie and breaks logout

IAM-1559

Admin and Enduser UIs not loading in IE11

IAM-1562

Sanitize postLogoutUrlClaim on redirection after Logout

IAM-1563

403 when attempting to read password policy for delgated admin reset password

10 Sep 2021

Issue ID Summary

FRAAS-7890

Validation of custom domains allows upper case domain names

FRAAS-8064

OATH Device not shown in End-User Profile Dashboard

IAM-1475

Issue with enduser platform-ui when compiled from source

IAM-1542

End users are unable to update their KBA info

IAM-1545

KBA Create node does not send custom question as part of payload

08 Sep 2021

Issue ID Summary

AME-20499

Using Social Identity Provider Selector node and having disabled social IDPs causes massive amounts of exceptions and errors in the logs

AME-20895

Request Object Encryption

AME-21056

Make request object 'aud' configurable

AME-21133

Apple Sign In Form POST Endpoint Compatibility with Custom Login Apps

OPENAM-16314

Create OAuth2/OIDC Node to allow same authentication methods used and supported by our own OpenID Connect provider and clients

OPENAM-17286

Add additional configuration options required for private key jwt feature

OPENAM-17494

Other ways to allow OTP SMS Sender and OTP Email Sender nodes to send custom message

OPENAM-17527

Support KMS/AM-encryption of PEM-format secrets

OPENAM-17581

Scripted decision node on /authentication/authenticationtrees/trees PUT breaks tree save

OPENAM-17625

No trees shown in inner tree selection box when another tree is misconfigured

OPENAM-17672

Page Node does not expose inner nodes inputs or outputs

OPENAM-17673

Nodes within a Page node do not have access to secure state

OPENIDM-16113

rsFilter is case sensitive, which triggers authentication errors

OPENIDM-16191

New live sync schedule created from UI is missing invokeContext.source

OPENIDM-16275

UI does not display Progressive Profile Query Filter Condition properly

OPENIDM-16322

Unable to create new LDAP connector through admin UI

OPENIDM-16335

NPE on org model children endpoint when making a request that contains an error

OPENIDM-16343

Unable to save powershell connector config through admin UI

OPENIDM-16388

LDAP Connector created through Admin UI not setting credentials and baseContexts

02 Sep 2021

Issue ID Summary

FRAAS-7996

Cannot remove org members when logged in as org admin

IAM-1421

Application Token lifetime input textbox not visible in some ID Cloud environments

IAM-1424

Platform UI application list page shows errors when viewed from a sub-sub-realm

IAM-1441

Custom Domain previous button is misplaced

IAM-1442

Too much space between realm avatar on realm title

IAM-1496

Platform admin theme editor missing default values for logo url/alt text

IAM-1514

In a list view, clicking directly on checkbox does not select row

IAM-1533

UI labels missing from ID Cloud registration UI

IAM-1537

Platform UI: Not able to update user when email is an optional attribute

IAM-1538

After changing password on a user in the admin ui any subsequent changes to the object results in an error on save

30 Aug 2021

Issue ID Summary

IAM-1531

UI submits string values for NumberAttributeInputCallback

23 Aug 2021

Issue ID Summary

IAM-1473

Unable to access links to native consoles if platform dashboard page not large enough

IAM-1492

Using 'reset to defaults' on theme admin wipes out theme name

IAM-1508

Edit managed user page has bad formatting when ListField inputs contain long entries

IAM-1509

Social login failure does not return to initial journey step

IAM-1515

Ensure login theme background covers entire height

17 Aug 2021

Issue ID Summary

FRAAS-7936

Email templates missing from console

IAM-1476

Change Consent menu item and related text to Terms & Conditions

16 Aug 2021

  • Updated End User UI to support WCAG accessibility best practices.

  • Updated End User UI and Login UI to support localization.

  • Updated End User UI theming and customization for user journeys:

    • Added ability to apply a different theme and logo to each user journey.

    • Added ability to provide a different user journey to each brand.

    • Added ability to add custom footers to end-user login and account management pages.

    • Added ability to configure the layout of the end-user account management page by adding and removing sections.

  • Updated End User UI terms and conditions management:

    • Added versioning and localization.

    • Added ability to track end-user version history.

Issue ID Summary

IAM-1259

EndUser-UI WCAG updates

IAM-1264

End user stored state returns different user to previous users page

IAM-1289

Platform-ui not rendering in IE11 because Postcss v8+ only serves ES6+ sources

IAM-1291

End user delegated admin should not display raw JSON option

30 Jul 2021

Issue ID Summary

FRAAS-7721

Unable to save a new LDAP connector configuration in the Platform UI

15 Jul 2021

Issue ID Summary

AME-20475

OpenID Connect Back-Channel Logout

AME-20499

Using Social Identity Provider Selector node and having disabled social IDPs causes massive amounts of exceptions and errors in the logs

AME-20600

Grant Types UI field the OAuth2 Provider shows as supportedGrantTypes

AME-20994

Rename StoreOps tokens to OIDC Session Management

IAM-1096

Scripted decision node description has a typo

OPENAM-14402

Access/ID tokens only include short username for "sub" claim

OPENAM-15214

Auth Tree - Clicking save with no changes causes render problem with node attributes inside page node

OPENAM-16314

Create OAuth2/OIDC Node to allow same authentication methods used and supported by our own OpenID Connect provider and clients

OPENAM-16653

Identity using fr-idm-uuid has wrong account ID in FR Authenticator

OPENAM-16959

Failed to authenticate with Twitter as Social Login Provider

OPENAM-17297

HOTP Generator Node adds cleartext OTP to sharedState

OPENAM-17436

JS version of the OIDC Claims script does not work due to a casting error.

OPENAM-17489

Add new form_post endpoint

OPENAM-17494

Other ways to allow OTP SMS Sender and OTP Email Sender nodes to send custom message

OPENAM-17517

JS versions of Social Identity Provider Profile Transformation scripts do not work due to a casting error.

OPENAM-17595

endSession should fail gracefully instead of Unknown JWT error

OPENAM-17625

No trees shown in inner tree selection box when another tree is misconfigured

OPENAM-17659

Select Identity Provider Node does not load social IDPs that do not define a client secret

OPENAM-17672

Page Node does not expose inner nodes inputs or outputs

OPENAM-17828

Apostrophe in username breaks Push/OATH device registration

OPENIDM-14525

Customer would like to define a default value for a property on a managed object.

OPENIDM-15220

Temporal constraints on internal role grants with privileges are not reflected in the end-user UI

OPENIDM-16192

Under certain conditions it is possible to generate two users with the same userName

OPENIDM-16206

TaskScanner tries to read object after deletion

OPENIDM-16266

ICF service retry during livesync network failures

OPENIDM-16326

SchemaService does not allow filtering on _id

OPENIDM-16334

Managed object schema editor fails on properties with "pattern : null"

28 Jun 2021

Issue ID Summary

OPENIDM-16678

Clustered recon fails with "Schedule does not exist"

23 Jun 2021

Issue ID Summary

FRAAS-4877

Attempting to Import a CSV file that contains a number in an frUnindexedInteger field fails

15 Jun 2021

Issue ID Summary

FRAAS-7322

Common passwords policy errors now show in bulleted list below password field

IAM-1264

Logging out and logging back in now returns user to dashboard instead of last route visited

IAM-1319

Allow disabling of sorting and searching on relationship array grids

IAM-1321

Allow UI to use post_logout_url claim from id_token for redirection after logout

10 Jun 2021

Issue ID Summary

FRAAS-6504

Terms and Conditions do not render correctly when using HTML formatting directives

IAM-1081

Using the back button in some UI contexts causes an session termination

OPENAM-17297

HOTP Generator Node adds cleartext OTP to sharedState

OPENAM-17343

Access token call returns 500 error if password needs to be changed or has expired

OPENAM-17349

OIDC Refresh token - Ops token is deleted from the CTS during refresh EDISON

OPENAM-17352

OAuth Introspection Endpoint can be accessed by public clients providing an empty client secret

OPENAM-17359

Unfriendly error message displayed when an expired link from "email suspend" node is used

OPENAM-17396

Terms of Service URI Link does not Display in Consent Page

OPENAM-17426

No validation for attribute collector node

OPENAM-17436

JS version of the OIDC Claims script does not work due to a casting error.

OPENAM-17494

Other ways to allow OTP SMS Sender and OTP Email Sender nodes to send custom message

OPENAM-17517

JS versions of Social Identity Provider Profile Transformation scripts do not work due to a casting error

OPENAM-17595

endSession should fail gracefully instead of Unknown JWT error

OPENAM-17625

No trees shown in inner tree selection box when another tree is misconfigured

OPENAM-17672

Page Node does not expose inner nodes inputs or outputs

OPENAM-17673

Nodes within a Page node do not have access to secure state

OPENAM-17828

Apostrophe in username breaks Push/OATH device registration

OPENIDM-15953

Connector Config Disappears from UI in IDCloud for RCS Connectors

OPENIDM-15903

Grant Type not shown in the Grant Column for Assigned Roles

OPENIDM-16134

/system?_action=createFullConfig unexpectedly replaces variables

OPENIDM-16150

Identity Connect UI - Manage Admin Groups modal does not have cancel button after adding new Group Base Contexts

OPENIDM-16180

Removed Properties cannot be Re-Added Until Page Refresh in User Registration

04 Jun 2021

Issue ID Summary

IAM-1219

JS error when assigning multiple relationships

IAM-1261

Adding relationship via UI fails when large user populations

IAM-1263

Need some default data in managed object lists when search filter on UI

IAM-1290

Managed identities configuration cosmetic improvements

20 May 2021

Issue ID Summary

FRAAS-6854

When the commonly-used passwords option is selected for password policy…​option unusable

FRAAS-6012

Remove Restriction in UI of Only Allowing One Domain

FRAAS-5525

Add CORs Settings to New Platform UI

FRAAS-4017

On all journey drag-and-drop UIs, links to SDK/API Docs are broken

IAM-1242

SDK config for CORS settings doesn’t properly set allowCredentials

IAM-1240

Fix styling of Multiselect Dropdown and tags

IAM-1228

Platform ui scripting issues seen in ID cloud testing

IAM-1227

remove dependency that requires 'parent required' for UI to handle orgs properly

IAM-1213

Input Label and Placeholder doubling up on all input fields

IAM-1212

Unable to use Webauth TouchID or FaceID on Safari MacOS/iOS

IAM-1205

Update copyright bot copyright message GoodFirstIssue

IAM-1195

Adding a temporal constraint to a role member relationship does not work

IAM-1181

IDM policies not displayed in policy panel for password

IAM-1177

Update grids to handle large datasets based on managed object schema flag

IAM-1160

Server list doesn’t update on new server cluster modal

IAM-1155

Improve code coverage display in PR testing

IAM-1151

Multiselect Does Not Remove Entry If Removed When Entering New Value GoodFirstIssue

IAM-1148

Remove JEST snapshot testing

IAM-1105

Disable save button on new connector server modal after first click GoodFirstIssue

IAM-1076

When in cloud env hide bravo_user, bravo_role, and bravo_assignment when realm is alpha and vice versa

IAM-1065

E2E Tests - Admin - Import Identities

IAM-1039

Platform Scripting Usability (UI Only)

IAM-1024

Adjust app detail header top margin

IAM-375

Refreshing Page on Alias Doesn’t Highlight Side Menu Item

28 Apr 2021

Issue ID Summary

FRAAS-6503

Turn Off The End User Hosted hosted profile page

IAM-1001

Remove extra padding on login error

IAM-1144

Email Templates - Create Email Provider View

IAM-996

Remove extra spacing on Agent profile status button

12 Apr 2021

Issue ID Summary

FRAAS-6573

SAML2 login flow ends with error: “No mapping organization found for organization identifier”

FRAAS-6465

Social login seems to break expected goto URL behavior when protecting apps with IG

IAM-1165

Sidebar-shim Does not Dynamically Change on Resolution Change

IAM-1120

End user account controls throwing invalid argument error on profile page load

IAM-1080

Convert switches to checkboxes in journey editor

OPENAM-17625

No trees shown in inner tree selection box when another tree is misconfigured

OPENAM-17517

JS versions of Social Identity Provider Profile Transformation scripts do not work due to a casting error

OPENAM-17494

Other ways to allow OTP SMS Sender and OTP Email Sender nodes to send custom message

OPENAM-17436

JS version of the OIDC Claims script does not work due to a casting error

01 Apr 2021

Issue ID Summary

FRAAS-6504

Updated terms callback to sanitize html from backend

FRAAS-6431

End User UI calls ../authenticate endpoint switch at login

FRAAS-6399

ID Cloud UI Multiselect spinner

FRAAS-6255

Tenant Admin List does not always Show Entire List of Admins

FRAAS-5968

End User Profile Page Displays "ForgeRock" Specific Information

FRAAS-5585

Custom Domain - UI Re-Verify Flow

IAM-1179

Fix issue with managed identities table not displaying properly

IAM-1171

Drag selection in the journey editor can cause console errors cause saving to hang

IAM-1165

Sidebar-shim Does not Dynamically Change on Resolution Change

IAM-1142

Duplicate Journey modal breaks if initially dismissed

IAM-1141

Update password policy messages to a more user friendly format in the Platform-UI.

IAM-1128

Resource view cutting off dropdown menu

IAM-1126

Login-UI doesn’t change locale language to browser default

IAM-1109

Realm theme logo preview doesn’t update

IAM-1104

Not possible to change or remove the default locale of email templates.

IAM-1083

Email template "From" input field limited to email addresses while label suggests otherwise

IAM-1080

Swap toggle w/ checkbox in journey editor

IAM-1040

Journey list page displays javascript errors when expanding a journey

OPENIDM-15019

End-user UI displays user name without accents (umlaut etc)

11 Mar 2021

  • Added Salted SHA-256 support.

Issue ID Summary

FRAAS-6209

Theme Editor popover() does not display using Firefox on MacOS

FRAAS-6199

Ugly Error Messaging in UI when Password Policy Fails

FRAAS-6099

AM Authorization with Advices broken

FRAAS-6013

When you enter a domain in the Domain Modal, and it Fails Validation, you cannot add a Domain that is Valid

FRAAS-5968

End User Profile Page Displays “ForgeRock” Specific Information

FRAAS-5938

Platform UI generates forbidden Journey title and cannot be deleted

FRAAS-5843

Current password policy limits passwords to a maximum of 64 characters

FRAAS-5756

Authentication Trees Don’t Respect reentry Cookie

FRAAS-5340

Hashed passwords synchronization fails

IAM-794

Platform login UI has hard-coded “/am” path assumed for default path behavior

IAM-1124

Can’t save Agent type RCS on edit page

IAM-1103

Password policy shows ‘must be less than 0 characters long’ when max length is 0

IAM-1097

Incorrect instruction link for RCS in IDCloud docs

IAM-1088

Add show columns, sort, and search capability to relationship array grid

IAM-1087

Admin create resource modal should handle required relationship array properties

IAM-1081

Using the back button in some UI contexts causes an session termination

IAM-1021

Ability to copy and paste values from multiselect component

IAM-1017

Force Use SSL option for Connector Servers in Cloud

OPENAM-16949

Cannot create a policy for subject type group

17 Feb 2021

Issue ID Summary

IAM-1066

Links for delegated admin objects not showing in end-user UI when a user has correct privileges

IAM-1064

Incomplete provisioner file makes it impossible to create clusters

IAM-887

Admin UI does not display in the Firefox web browser when Private Browsing is enabled.

04 Feb 2021

Issue ID Summary

OPENAM-17289

Generated id_token does not contain any of the requested claims, other than "sub".

OPENIDM-15892

Persisted schedules not being displayed in IDM Native UI

29 Jan 2021

13 Jan 2021

Issue ID Summary

AME-20719

RelayState Not Being Used on Identity Cloud with SAML tree node

AME-13690

Create an OATH authentication node

FRAAS-5257

Cannot disconnect social identity provider

IAM-1003

IE11 does not search for user on End User page

IAM-989

Update connection status for servers on server cluster pages

IAM-988

Platform UI error for end users when resizing in IE 11

IAM-978

ConnectorServers generates browser console errors when connector servers are present

IAM-958

Backend scripts updating hiddenValueCallback values don’t propagate to step requests

IAM-952

ID cloud new server cluster modal allows going back to select adding servers when it should not

IAM-947

Platform UI: support 'default' values in Managed Object create/edit screens

IAM-907

Adding IG Agent with non-unique name breaks UI

OPENAM-16965

Alignment of shared state with self-service object nodes

OPENAM-16961

OIDC Claims Script - /userinfo to access clientProperties

OPENAM-16919

SAML JSP Flows not working

OPENIDM-15686

Cannot delete a mapping in an Identity Cloud tenant

OPENIDM-15576

Unable to save the 'Reconciliation Query Filters' under Mappings in the Admin UI.

OPENIDM-15511

IDM Admin console - Paging controls in managed objects are disabled

OPENIDM-15507

Paging controls in connector data tab are disabled and should not be

OPENIDM-15368

Value of ldapGroups isn’t visible in the admin UI as an assignement attribute

OPENIDM-15150

IE11 script error in End-User UI

OPENIDM-14750

Managed Object schema editor scripts tab not saving scripts on relationship type properties

OPENIDM-14411

Unable to create a user with a previously used password

08 Nov 2020

Issue ID Summary

AME-20500

Users cannot authenticate using local authentication and the Social IDP Selector node

FRAAS-4856

Cannot create API keys using Safari 14.0

FRAAS-4767

Identity Cloud UI does not display user properties according to managed object settings

FRAAS-4699

Connector server (RCS) connection status inaccurate

FRAAS-4481

Enduser UI - Password required in Edit Personal Info

FRAAS-4070

Update tenant naming convention

IAM-906

Cannot create an assignment when the mapping target is a system object

IAM-885

ID cloud journeys list has visual errors for journeys created in AM native console

IAM-882

Breadcrumb needs to update upon navigating away from page

IAM-881

End-user profile doesn’t render multi-value fields

IAM-862

Footer has wrong logo

IAM-861

Change managed object toggle to show object value instead of entire schema

IAM-795

Bulk Import: improve error messages in Identity Cloud Admin UI

IAM-784

Add dynamic theme for end user

IAM-759

Incorrect URL for legacy AM admin console

IAM-697

Platform-admin Unit tests: Applications

IAM-606

Allow Password entry in 'New Identity' Modal

IAM-589

Accessibility: CardRadioInput is not navigable and doesn’t report as a radio input correctly

13 Oct 2020

02 Oct 2020

  • Improved IDM debug logging.

  • Custom attributes can be used in scripts.

  • Added Gateways & Agents list and profile page.

  • Journey edit page indicates required fields.

  • Updated dark theme.

  • Added the ability to theme the login UI from config.

Issue ID Summary

FRAAS-4610

Filename with a space gets converted to an null pointer

FRAAS-4558

Admin invite doesn’t work

FRAAS-4550

User profile attributes are inaccessible to token modification scripts

FRAAS-4549

Base URL Source service should be part of quickstart config

FRAAS-4522

Cannot save "Generic Indexed String" attributes in user profile

FRAAS-4520

Cannot save "Address 1" field in user profile properties

FRAAS-4477

Password-related failures at onboarding

FRAAS-4459

Make createResource behave more consistently with repeat use.

FRAAS-4440

Broken create assignment functionality

FRAAS-4379

UI issues with OAuth 2.0 related interfaces (Consent page, OAuth 2.0 client error pages, and the device code grant page

FRAAS-4319

Alpha/Bravo Realm Users cannot edit personal info in the Enduser UI

FRAAS-4277

Hide incompatible tree nodes

FRAAS-3928

Remove on-prem connectors from PaaS IDM instance

IAM-789

Password policy rules should display in platform-admin password reset UI

IAM-603

403/404 errors in platform-admin when user has insufficient privileges

Coming Soon

Issues that will provide new features or bug fixes in an upcoming release.

Subscribe to get automatic updates: Coming soon RSS feed

Platform

   Updated 18 Jan 2022. Release pending.

  • Update to the staging environment information on the tenant status page. Individual service statuses will be combined into a single status.

   Updated 12 Jan 2022. Release pending.

  • Adding language localization to hosted pages.

  • Adding ability to extend the user identity schema with custom attributes.

  • Adding new built-in connector for Microsoft Graph.

Issue ID Summary

AME-22153

Default client-side authentication script is incorrect

OPENAM-18241

Permit OAuth2 Modification Script to return scopes as space-delimited string

UI

   Updated 12 Jan 2022. Release pending.

Issue ID Summary

IAM-1687

Use the first populated locale when duplicating Terms and Conditions

IAM-1723

Add datepicker to date fields

IAM-1724

Add duration chooser to duration fields

IAM-1747

Optional node attributes default to empty strings in request JSON when saving journey

IAM-1757

Adding security question translation causes KbaCreateNode to loop

IAM-1762

Show all available page numbers in pagination for application and script list views

IAM-1764

Default starter theme UI in security question picker is too dark

IAM-1769

Policy list has console scrollIntoView error

IAM-1774

Add translated values to alt text entries and aria-label entries

IAM-1788

Incorrect URL is copied for journeys after search filtering

IAM-1792

Goto param in start over link is not URL encoded

IAM-1813

Journey list page flashes empty state instead of loading state

IAM-1825

Show user avatar and name for user identities