Migration and customization

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

Ping Advanced Identity Software offers maximum extensibility and flexibility in self-managed deployments. It includes many features and options the sample setup instructions don’t cover. If you don’t need maximum extensibility and flexibility, there are simpler alternatives:

To consume Ping Advanced Identity Software as a service, use PingOne or Advanced Identity Cloud instead.
To deploy Ping Advanced Identity Software in Kubernetes, start with the ForgeOps reference implementation.

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

Previous versions of Ping Advanced Identity Software provided a sample deployment called the full stack sample. Ping Identity no longer supports this kind of deployment for integrations between PingIDM and PingAM. Follow the steps outlined here to set up a new deployment. There’s no automated migration facility for an existing deployment based on the old full stack sample, but you can follow the tips in this chapter to help you move to a new integrated deployment.

This isn’t an exhaustive list, and you’ll have additional configuration changes to make, based on how you deployed the full stack sample.

Self-service configuration

All self-service configuration is now done in the PingAM UI, with the exception of the following elements:

KBA
Terms & Conditions
Policies
Privacy & Consent
Email templates and services

You can therefore delete all the PingIDM selfservice* files from your configuration, apart from selfservice.kba.json and selfservice.terms.json. These two files are still used by the new PingAM authentication trees.

You will need to rebuild all existing self-service processes as PingAM authentication trees. Note that tree nodes are more modular than the legacy PingIDM self-service stages. It might take more than one node to replace a self-service stage.

Authentication

Integrated deployments now use a single rsFilter authentication module that allows authentication using PingAM bearer tokens. You must replace your project’s conf/authentication.json file with this authentication.json file and customize it, according to your setup.

Configure OAuth clients and the PingIDM provisioning service in the PingAM UI.

UI customization

The Platform admin UI is the primary interface for administering PingAM and PingIDM in an Advanced Identity Software deployment. Learn more in UI customization.

Migration for shared identities

As shown in Shared identity store, PingAM and PingIDM can share a PingDS identity store. Since version 7, this is a well-supported and recommended deployment pattern.

Previously, as shown in Separate identity stores, PingAM used a PingDS-based identity store, PingIDM used a relational database for its repository, and PingIDM synchronized identities between them.

When you migrate shared identities to a shared PingDS identity store, follow these high-level steps:

Add any custom identity attributes to the shared identity store and Advanced Identity Software components.

Many deployments define custom attributes that serve in profiles or security tokens, which are critical to authentication and authorization, such as OAuth 2.0 access tokens, OpenID Connect ID tokens, and SAML assertions.

Find detailed instructions in Custom attributes.
Use PingIDM to migrate identity data to the shared PingDS identity store.

Make sure that any operations to modify managed objects, such as managed users, performed as part of the mapping (in sync.json), are reflected in the managed object schema (in managed.json).

Learn more in Migrate data in the PingIDM documentation.