Migrating from ForgeRock

ForgeRock (now part of Ping Identity as PingAM and PingIDM) has been a foundational Identity and Access Management platform in large enterprises, particularly in financial services, telecom, and the public sector. Whether motivated by an upcoming End of Support milestone, a strategic re-evaluation of the platform, or a desire to consolidate on a focused authorization server, organizations on PingAM frequently look at alternatives. For teams whose requirements center on OAuth 2.0, OpenID Connect, and modern API security, the Curity Identity Server provides a focused and standards-first successor.

Because OAuth and OpenID Connect are portable standards, you can run the bulk of a migration as an organized, configuration-driven project. ForgeRock concepts such as realms, authentication trees, scripted decision nodes, and OAuth2 Providers each have a natural counterpart in the Curity Identity Server.

This article focuses on what a transition to the Curity Identity Server looks like for organizations that decide to evaluate alternatives.

Scope of This Migration

The ForgeRock Identity Platform is broader than a single product, so scope the migration correctly.

• PingAM (ForgeRock AM) - access management, federation, OAuth 2.0 / OIDC, authentication trees, adaptive auth, session management. This is the primary scope of a Curity migration.
• PingIDM (ForgeRock IDM) - user provisioning, synchronization, reconciliation, and workflow orchestration. The Curity Identity Server is not an IGA product. Replace IDM functionality with a dedicated provisioning tool, or with a combination of SCIM-based data flows and directory synchronization.
• PingDS / OpenDJ - directory service. Keep it as a data source behind the Curity Identity Server, or replace it with any LDAP, SQL, or SCIM-capable store.

This article focuses on replacing PingAM. However, it also covers identity data and user storage where they intersect with authentication and token issuance.

API Security with Curity

The Implementing Zero Trust APIs article summarizes the architecture Curity recommends when protecting APIs.

• Each API verifies a JWT access token on every request, in a zero trust manner
• Internet clients receive opaque tokens, as a privacy best practice
• An API gateway introspects opaque access tokens, then forwards JWTs to APIs
• Each API uses claims from the JWT to implement its business authorization

ForgeRock deployments commonly use Policy Agents or Identity Gateway (IG) to enforce access at the perimeter, often against reference tokens or session cookies. When you migrate to the Curity Identity Server, replace this pattern with the Phantom Token approach, where your existing API gateway (NGINX, Kong, Apigee, AWS API Gateway, and others) handles introspection and forwards a JWT to the upstream API. This removes the need for a ForgeRock-specific agent on every protected resource.

Authentication Concepts

ForgeRock users will be familiar with Authentication Trees (or the older Authentication Chains), where nodes such as Username Collector, Data Store Decision, Push Sender, and scripted decision nodes are composed into a flowchart. The equivalent in the Curity Identity Server consists of two concepts.

• Authenticators - the mechanism by which a user logs in (username/password, BankID, WebAuthn, OIDC to an upstream IdP, SAML, and so on).
• Authentication Actions - logic that runs before, between, or after Authenticators. Authentication Actions are where you implement MFA step-up, risk checks, account linking, attribute transformation, and consent.

A ForgeRock Authentication Tree with a Data Store node followed by a Push Authentication node with a scripted risk decision maps naturally to a Curity authenticator chain with an Authentication Action that evaluates risk and conditionally requires a second factor. See the Authentication Actions Concepts and MFA Using Authentication Actions articles for examples.

Rewrite any scripted decision nodes written in Groovy or JavaScript against AM's Scripted Decision node API. Simple logic can become a JavaScript procedure. For anything substantial, choose an Authentication Action plugin. Note that AM 7.5 ships both a legacy and a next-generation scripting engine with different bindings, so scripts still on the legacy engine face a rewrite within ForgeRock as well.

Migrate Configuration

ForgeRock stores configuration in a file-based configuration store (FBC) with JSON documents, managed through the AM console, the ssoadm/Amster CLI, or REST APIs. The Curity Identity Server stores security configuration as XML, which is fully declarative, parameterizable, and version controllable. It stores user accounts and token-related state in a database.

Import Configuration

In a simple setup you can add configuration via the Admin UI. In more complex setups, scripts can read the ForgeRock configuration (typically exported via Amster) and transform it into Curity configuration, then apply it either through the RESTCONF API or the CLI. The configuration reference documents the full schema.

Most commonly, use PATCH operations to merge data into the existing configuration.

curl -k -s \
    -X PATCH "$RESTCONF_BASE_URL" \
    -u "$ADMIN_USER:$ADMIN_PASSWORD" \
    -H 'Content-Type: application/yang-data+xml' \
    -d @./config.xml

The following snippet shows a configuration with a single OAuth client registered on the Token Service profile. Apply the same technique for Authenticators, Authentication Actions, claims, scopes, and data sources.

<data xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">
    <profiles xmlns="https://curity.se/ns/conf/base">
        <profile>
            <id>token-service</id>
            <type xmlns:as="https://curity.se/ns/conf/profile/oauth">as:oauth-service</type>
            <settings>
                <authorization-server xmlns="https://curity.se/ns/conf/profile/oauth">
                    <client-store>
                        <config-backed>
                            <client>
                                <id>web-client</id>
                                <client-name>web-client</client-name>
                                <description>Migrated from ForgeRock OAuth2 Provider</description>
                                <secret>secret1</secret>
                                <redirect-uris>https://www.example.com/callback</redirect-uris>
                                <scope>openid</scope>
                                <scope>profile</scope>
                                <capabilities>
                                    <code/>
                                </capabilities>
                            </client>
                        </config-backed>
                    </client-store>
                </authorization-server>
            </settings>
        </profile>
    </profiles>
</data>

Parameterize Configuration

The Curity Identity Server allows you to export the configuration as a whole or in parts into an XML file. It encrypts sensitive values, and you can fill in any parameter placeholders at deployment time. As a result, you can put the configuration file under version control and use it in your deployment pipelines, avoiding the drift that often develops in ForgeRock environments where changes are made through the console in one environment and replicated manually elsewhere.

You only need to do the import work once, at an early stage of your deployment pipeline, typically a development environment. See the IAM Configuration Best Practices and Configuration as Code articles for further details on managing configuration in the Curity Identity Server.

Design Deployment

Where possible, deploy the Curity Identity Server as a replacement for ForgeRock and keep the same external URLs. This keeps code and configuration changes in your APIs and user facing applications to a minimum.

Deployment Resources

Both ForgeRock AM and the Curity Identity Server can run as Docker containers, though ForgeRock AM is traditionally deployed as a WAR on Tomcat. Run the following command to start a standalone Curity instance with a backed-up configuration.

docker run -it -p 6749:6749 -p 8443:8443 \
    -e CONFIG_ENCRYPTION_KEY="$KEY" \
    -e ADMIN='true' \
    -v "$(pwd)/config-backup.xml":/opt/idsvr/etc/init/config.xml \
    curity.azurecr.io/curity/idsvr:latest

In a real-world deployment, create a custom Docker image that includes other resources, such as customizations to the look and feel, or plugins that extend functionality.

Migrate Endpoints

ForgeRock exposes endpoints under a realm path. The following shows an example of an OpenID Metadata endpoint with ForgeRock.

https://login.example.com/am/oauth2/realms/root/realms/alpha/.well-known/openid-configuration

In the Curity Identity Server, you configure the path for each endpoint separately, so you can preserve existing URLs. You can also create copies of endpoints for special use cases, such as a second token endpoint that requires mutual TLS, or a separate authorize endpoint for FAPI 2.0 clients. Any edits appear immediately in OpenID Connect metadata.

Realms and Multi-tenancy

Each ForgeRock realm maps to a Curity profile. For deployments with many realms, use server roles to control which runtime instances expose which profiles. This isolates workloads such as internal employees, B2C consumers, and machine-to-machine traffic. For further details on advanced deployments, see the Multi-tenancy and Deployment Concepts articles.

Migrate API Permissions

ForgeRock typically issues JWT access tokens through its OAuth2 Provider, with scopes defined in the provider settings and additional values populated through OIDC claims scripts or OAuth2 access token modification scripts.

In the Curity Identity Server, you map claims to scopes and configure scopes against clients. The Token Designer provides complete control over which claims are included in which tokens, or from the UserInfo endpoint.

<scopes>
    <scope>
        <id>transactions</id>
        <description>Read account transactions</description>
        <claims>sub</claims>
        <claims>customer_id</claims>
        <claims>entitlements</claims>
    </scope>
</scopes>
<claims>
    <claim>
        <name>entitlements</name>
        <description>Fine-grained business entitlements</description>
        <value-provided-by>entitlements-claims-provider</value-provided-by>
    </claim>
</claims>

Extensible Claims

Claims are a high value area when protecting your data, and in many cases you need to include claims from your business data, or APIs, at the time of token issuance. Migrate ForgeRock access token modification scripts that enrich tokens with data from external systems to claims value providers in the Curity Identity Server. Expressing business authorization as claims derived at token issuance time is Curity's preferred pattern, and it typically simplifies logic that was spread across multiple ForgeRock scripts.

Migrate Clients

OAuth 2.0 client registrations in ForgeRock, whether agent-based or stored as OAuth 2.0 Client objects, migrate to the Curity Identity Server's client store. Preserve client IDs and secrets so that your applications need no reconfiguration. Client attributes such as redirect URIs, allowed scopes, grant types, token lifetimes, and PKCE requirements map one-to-one.

Use this moment to tighten security settings that were historically relaxed on ForgeRock. Require PKCE for all public clients, enforce mTLS or private_key_jwt for confidential clients, and enable Pushed Authorization Requests.

If you work in a regulated sector, you can enable Curity's support for FAPI 2.0, DPoP, JARM, and JWT Secured Authorization Requests at this stage with configuration alone.

Migrate Federation

ForgeRock has extensive SAML 2.0 and OIDC federation capabilities, configured through Circle of Trust and hosted or remote IdP and SP entities. In the Curity Identity Server, these capabilities are configured through Authenticators and Service Provider entries.

• Configure SAML Identity Providers as Authenticators, and Service Providers as SAML service provider entries. See Integrating with SAML Identity Providers and Integrate a SAML Website.
• Configure upstream OIDC providers, including Microsoft Entra ID, Okta, etc., as OIDC Authenticators. See the Identity Providers Overview.

Re-exchange SAML metadata with your federation partners. You can typically preserve entity IDs and binding URLs, which avoids changes on the partner side.

Migrate Crypto Assets

Import cryptographic material into the Curity Identity Server's configuration, including PKCS#12 files used for token signing, certificates and keys used for TLS or mutual TLS, and trust stores. When first getting set up, use the facilities menu in the Admin UI. Other resources, such as advanced clients or token issuers, can then reference those keys.

The Curity Identity Server always imports and exports secrets in a protected form. The Configuration as Code tutorial shows how to provide secrets using a config encryption key, while also using parameterized configuration.

Migrate Users

ForgeRock typically stores user accounts in OpenDJ/PingDS or an external LDAP or relational database, accessed through its Identity Stores. The Curity Identity Server uses Account Manager and Credential Manager abstractions for accessing identity data and credentials. You have two migration options:

• Connect the Curity Identity Server to the existing store. If your user data lives in LDAP or SQL, Curity can often read it in place. Custom schemas may require a Java or Kotlin plugin, but this approach avoids a user data migration entirely and is usually the fastest route to parity.
• Migrate to Curity's schema. If you want to consolidate or retire the existing directory, migrate users with an ETL process that writes through SCIM or GraphQL. The schema of the Curity Identity Server includes an attributes field, usually stored as JSON, which is a convenient home for ForgeRock-specific custom attributes.

You can usually import credentials that use standard password hashing algorithms (bcrypt, PBKDF2, Argon2) without re-hashing, so end users continue to log in with their existing passwords. Rather than migrating WebAuthn devices and linked social accounts up front, you can let users re-register them on next use.

Migrate Authentication Workflows

Authentication Trees and scripted decision nodes are often the most substantive part of a ForgeRock deployment. Migration follows this pattern:

1. Map each authenticator. Username Collector + Data Store Decision becomes Curity's HTML Form authenticator against the appropriate data source. Push Authentication, WebAuthn, and social login nodes map to the corresponding Curity Authenticators.
2. Express orchestration as Authentication Actions. Conditional logic, risk evaluation, account linking, MFA step-up, and attribute transformation become Authentication Actions, composed in order and applied to the relevant Authenticators or clients.
3. Rewrite scripts. Simple JavaScript logic ports to Curity's scripted procedures. Re-implement substantial Groovy logic that reads external systems or makes complex decisions as a Java Authentication Action plugin, compiled against the Curity SDK. See Getting Started with Authentication Plugins.
4. Migrate account linking. If you depended on ForgeRock's tree-based account linking, use Curity's Account Linking With Social Identity Providers and Account Creation after Login patterns.

Implement Your Look and Feel

ForgeRock login UIs are typically customized via the XUI or End-User UI, with custom themes and templates. The Curity Identity Server provides a default modern look and feel for all user facing screens. To quickly update it for your company's brand, use the look and feel section of the Admin UI, which saves customizations to the configuration. The UI Kit provides full control over HTML, CSS, and messages. The Curity Identity Server also supports per-client themes, which helps when a single deployment serves multiple brands that were previously separated into distinct ForgeRock realms or instances.

ForgeRock's XUI is itself a single page application that consumes AM's authentication REST API, so deployments with heavily customized login journeys often prefer to keep an SPA architecture rather than return to server-rendered pages. The HAAPI React App supports this. It is an out-of-the-box single page application for login screens, shipped as part of the UI Kit, where the Curity Identity Server returns Hypermedia Authentication API (HAAPI) JSON responses and the React application renders the screens. Authentication logic stays in configuration while the frontend remains familiar to web developers. The same theming capabilities apply, and teams that need more control can extend the React source or replace it entirely with their own frontend built on HAAPI. Applications continue to use the standard authorization code flow and need no awareness of HAAPI themselves.

Replace Policy Agents and Identity Gateway

If you rely on ForgeRock Web/Java Policy Agents or Identity Gateway to enforce access on web applications and APIs, plan a gateway strategy as part of the migration. Use an existing API gateway with the Phantom Token pattern, so that internet clients hold opaque tokens while APIs receive JWTs internally. Integrations exist for NGINX, Kong, Apigee, AWS API Gateway, Azure API Management, and others.

For web applications that previously sat behind a Policy Agent, the Token Handler pattern provides a modern equivalent that keeps tokens out of the browser entirely.

Deploy and Operate

Once integrated, your teams use the Curity Identity Server for many further security use cases. Engineering teams draw on the tutorials and code examples in the guides, and developers can build plugins to integrate custom behavior when required. DevOps teams use monitoring features, including OpenTelemetry tracing and the Grafana Dashboard for Prometheus metrics, to keep the system running reliably. This is typically a step up in observability from ForgeRock deployments, where integration with modern tracing systems usually requires custom work.

Conclusion

The Curity Identity Server supports migrations from other systems. Whether you are responding to a support lifecycle deadline, consolidating tooling, or moving to a more focused authorization server, a migration from PingAM is a manageable, configuration-driven project. If your existing OAuth 2.0 and OpenID Connect applications are coded in a portable way, application-side changes stay minimal. The substantive work concentrates in mapping authentication trees to Authenticators and Authentication Actions, migrating identity data, and replacing Policy Agents with a gateway-based enforcement pattern - all of which the Curity Identity Server has established patterns for.