Ping Identity Platform

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

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

Sample: separate identity stores

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

PingGateway serves as a single-point of entry for platform UI access:

separate-id-store

Sample: shared identity store

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

PingGateway serves as a single-point of entry for platform UI access:

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 PingAM OAuth 2 clients interact with the PingIDM resource server filter (rsFilter) to grant access through the Platform UIs:

client-interaction

  1. The Platform UIs send a request to the PingAM 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 PingAM 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 PingAM Authorization Endpoint, according to the GoTo request parameter.

  • Don’t use the PingIDM stand-alone End User UI if you’re deploying PingAM and PingIDM as a platform. This UI is delivered with PingIDM under ui/enduser. It is not the same as the platform-enduser UI and won’t work in a platform deployment.

  • By default, the IDM admin UI only supports users from the PingAM 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/.

Next step