ForgeRock Identity Platform 7.4

Choose your sample

This page describes the sample deployment alternatives and how the platform components interact.

This is not a comprehensive platform implementation guide. These sample setup instructions show a minimal integration of platform components to get you started.

The ForgeRock Identity Platform offers maximum extensibility and flexibility in self-managed deployments. The platform includes many features and options these sample setup instructions do not cover. If you don’t need maximum extensibility and flexibility, there are simpler alternatives:

  • To consume the platform as a service, use ForgeRock Identity Cloud.

  • To deploy in Kubernetes, start with the ForgeOps reference implementation.

For help with your deployment and to validate your plans before deploying in production, contact ForgeRock.

Sample: separate identity stores

This sample deployment has an external DS server configured as the AM configuration store and AM identity store (shown separately in the illustration). The IDM repository is an external JDBC database. The sample was tested with MySQL. The deployment uses an LDAP connector to synchronize the identities between IDM and AM:

separate-id-store

Sample: shared identity store

This sample deployment has an external DS server configured as the AM configuration store and shared by the AM and IDM servers share an external DS server as the identity store (shown separately in the illustration). No synchronization configuration is required:

shared-id-store

In both sample deployments, the Platform UIs can run in separate Docker containers. If you want to run the Platform UIs in containers, get Docker before you start.

Component interaction

A platform configuration relies on multiple components working together. The following image shows how the AM OAuth 2 clients interact with the IDM resource server filter (rsFilter) to grant access through the Platform UIs:

client-interaction
  1. The Platform UIs send a request to the AM Authorization Endpoint.

  2. If the end user is authenticated, the user agent is redirected back to the UI, according to the Redirection URI request parameter.

  3. If the end user is not authenticated, the AM Authorization Endpoint redirects the user agent to the Platform Login UI.

  4. After successful authentication, the Platform Login UI redirects the user agent back to the AM Authorization Endpoint, according to the GoTo request parameter.

  • Do not use the IDM stand-alone end-user UI if you are deploying AM and IDM as a platform. This UI is delivered with IDM under ui/enduser . It is not the same as the platform-enduser UI and will not work in a platform deployment.

  • By default, the IDM admin UI only supports users from the AM root realm. If you need to support users from other realms, adjust the /oauth2/ references in the /path/to/openidm/ui/admin/default/index.html file:

    commonSettings.authorizationEndpoint = calculatedAMUriLink.href + '/oauth2/authorize';
    
    AppAuthHelper.init({
        clientId: commonSettings.clientId,
        authorizationEndpoint: commonSettings.authorizationEndpoint,
        tokenEndpoint: calculatedAMUriLink.href + '/oauth2/access_token',
        revocationEndpoint: calculatedAMUriLink.href + '/oauth2/token/revoke',
        endSessionEndpoint: calculatedAMUriLink.href + '/oauth2/connect/endSession',

    For example, if your realm is named alpha, replace /oauth2/ with /oauth2/realms/root/realms/alpha/.

Copyright © 2010-2024 ForgeRock, all rights reserved.