Tools / ForgeRock IAM interview questions

ForgeRock is an enterprise Identity and Access Management (IAM) platform that provides a full suite of identity services — authentication, authorization, identity governance, directory services, and API gateway capabilities — all under a single integrated product family. It is now part of Ping Identity (acquired in 2023) and is sold as PingOne Advanced Identity Cloud in its SaaS form and as the standalone ForgeRock Identity Platform for self-managed deployments.

The platform is built around four core products that work independently or as an integrated stack:

AM is the most interview-tested component — it handles all authentication and authorization decisions. DS backs AM's session and CTS (Core Token Service) storage. IDM manages the full user lifecycle including connector-based provisioning to HR systems, Active Directory, and cloud apps. IG protects legacy applications that cannot natively speak OAuth2 or SAML by acting as a mediating gateway in front of them.

ForgeRock Access Management (AM) is the authentication and authorization hub of the ForgeRock platform. It is the component that users actually interact with when logging in, and the one that downstream applications call to validate sessions and enforce access policies. AM evolved from the open-source OpenAM project (itself rooted in Sun Microsystems' OpenSSO) and has grown into a full-featured identity provider and policy decision point.

AM supports a comprehensive set of identity and federation protocols:

• OAuth 2.0 — Token-based authorization framework; AM acts as both Authorization Server and Resource Server.
• OpenID Connect (OIDC) — Identity layer on top of OAuth 2.0; AM issues ID tokens and exposes a UserInfo endpoint.
• SAML 2.0 — XML-based SSO federation; AM can be both Identity Provider (IdP) and Service Provider (SP).
• WS-Federation / WS-Trust — Legacy Microsoft federation protocols for integration with AD FS environments.
• CAS (Central Authentication Service) — Widely used in academic environments; AM supports CAS SSO out of the box.
• FIDO2 / WebAuthn — Passwordless authentication using hardware security keys or platform authenticators.
• RADIUS — For VPN and network device authentication use cases.
• OATH (TOTP/HOTP) — Time-based and counter-based OTP for MFA flows.

AM also exposes comprehensive REST APIs so that custom applications can drive authentication, session management, and policy evaluation programmatically without going through the default UI flows.

Authentication Trees — rebranded as Journeys in AM 7.x — are the modern way to design authentication flows in ForgeRock AM. Introduced in AM 6.5, they replace the legacy authentication chain + module model with a visual node-based graph. Each tree is a directed acyclic graph (DAG) where every node performs a discrete task (collect a username, validate a password, check device fingerprint, send an OTP) and has one or more outcome paths that connect to the next node.

The key differences from the old module-based approach:

Trees also support inner trees (embedding one tree inside another as a node), which promotes reuse — for example a common MFA sub-tree shared across multiple top-level login journeys. The legacy chain model cannot be nested in this way. ForgeRock strongly recommends migrating all new deployments to trees; legacy modules are still supported for backwards compatibility but receive no new feature investment.

A Realm in ForgeRock AM is an administrative boundary that provides isolated configuration of identity stores, authentication trees, OAuth2 providers, policies, and agents. Every AM installation has a top-level root realm (denoted /), and administrators can create any number of sub-realms underneath it. Each realm operates as a logically independent IAM domain within the same AM deployment.

Realms are used primarily for multi-tenancy. Consider a large organisation with separate business units — HR, Finance, and Customer Portal — each needing its own identity store, its own authentication policies, and its own set of OAuth2 clients. Rather than deploying three separate AM instances, you create three realms. Configuration in one realm has zero visibility into another, even though they share the same AM infrastructure and CTS token store.

Concrete things that are configured per-realm:

• Identity data stores (which LDAP directory or DS instance backs users in this realm)
• Authentication trees and chains
• OAuth2 provider settings (issuer, token lifetimes, JWKS endpoint)
• SAML2 entity providers
• Policy sets and policies
• Agent profiles (Java agents, Web agents, IG agents)
• Password policies

DNS aliases can be mapped to specific realms so that hr.example.com/login routes automatically to the HR realm and finance.example.com/login routes to the Finance realm. This is done through the realm's DNS aliases configuration. Users in different realms are completely separate identity populations — a user object in the HR realm and a user object with the same username in the Finance realm are distinct entities.

ForgeRock AM acts as a fully compliant OAuth 2.0 Authorization Server. It issues access tokens, refresh tokens, and (when OIDC is enabled) ID tokens. The OAuth2 provider is configured per-realm, which means different business units can have different token lifetimes, signing keys, PKCE requirements, and scope policies within the same AM deployment.

AM supports all five major OAuth 2.0 grant types defined in RFC 6749 plus several extensions:

• Authorization Code — Standard redirect-based flow; supports PKCE (RFC 7636) to prevent authorization code interception attacks.
• Implicit — Deprecated in OAuth 2.1; still available but not recommended for new applications.
• Resource Owner Password Credentials (ROPC) — Direct username/password exchange; only appropriate for trusted first-party clients.
• Client Credentials — Machine-to-machine authentication where no user is involved; the client authenticates using its own credentials.
• Refresh Token — Exchange a refresh token for a new access token without re-authentication.
• Device Authorization Grant (RFC 8628) — For input-constrained devices (smart TVs, CLI tools) that cannot host a browser redirect.
• Token Exchange (RFC 8693) — Allows trusted services to exchange one token for another, enabling delegation and impersonation patterns.

Token format is configurable: AM can issue opaque bearer tokens (random strings stored in CTS) or stateless JWT access tokens. JWT tokens are self-contained — resource servers can validate them locally using AM's published JWKS without a round-trip to AM's introspection endpoint, improving performance at scale. Scopes in AM are validated against a configurable scope implementation — either a built-in provider or a custom scripted scope handler written in JavaScript or Groovy.

The Core Token Service (CTS) is the central token storage layer in ForgeRock AM. It is a key-value store backed by ForgeRock Directory Services (DS) that persists all transient token and session state that AM needs to maintain across cluster nodes. Without a shared CTS store, an AM cluster cannot provide seamless failover — if a user's session was pinned to a node that restarts, they would be forced to re-authenticate.

CTS stores several categories of objects, each with a configurable time-to-live:

• AM SSO Sessions — The stateful session records for authenticated users. Contains session properties, idle timeout, max timeout, and the authentication level.
• OAuth2 / OIDC Tokens — Access tokens, refresh tokens, and authorization codes when opaque (non-JWT) tokens are used. JWT access tokens validated locally do not need CTS storage.
• SAML2 Assertions and Sessions — SP session indexes and IdP session data needed for Single Logout.
• Device Fingerprints and Push Notifications — State for multi-step authentication flows such as push approval challenges.
• UMA Tokens — Requesting Party Tokens (RPTs) and Permission Tickets for User Managed Access flows.

The DS instance backing CTS is performance-critical. It is typically deployed in a dedicated DS topology separate from the user identity store — the two have very different access patterns. CTS sees high write throughput (new sessions and token rotations) and needs low-latency reads, so it benefits from SSD storage and a sufficient memory cache. In AM 7.x, token compression and optional Hazelcast-based in-memory caching were introduced to reduce DS read load for high-volume deployments.

ForgeRock Identity Management (IDM) is the lifecycle and provisioning engine of the ForgeRock platform. Where AM focuses on authentication and access decisions in real time, IDM manages the full identity lifecycle — creating accounts when a new employee joins, updating attributes when roles change, and deprovisioning access when someone leaves. It evolved from the OpenIDM open-source project and is designed to be embedded in enterprise HR-to-IT provisioning workflows.

IDM's architecture centres on a few key concepts:

• Managed Objects — The internal identity objects IDM maintains in its own repository (typically a relational database or DS). A managed user, managed device, or managed role is a canonical representation that IDM owns and governs.
• System Objects — Representations of objects in external target systems (Active Directory users, Salesforce contacts, etc.), accessed via connectors.
• Connectors (ICF) — The Identity Connector Framework provides adaptors to external systems. ForgeRock ships connectors for LDAP, Active Directory, SQL databases, Salesforce, Google Workspace, ServiceNow, CSV files, and others. Custom connectors can be written in Java using the ICF API.
• Mappings — Define the attribute flow between source and target objects. For example, a mapping from managed user → Active Directory maps userName to sAMAccountName.
• Reconciliation — The process of comparing source and target populations to detect and resolve discrepancies (user exists in source but not target, or vice versa).
• Sync — Real-time event-driven updates pushed to targets when a source object changes.

IDM also handles self-service registration, password reset, and profile management through configurable UI templates backed by REST APIs.

ForgeRock Directory Services (DS) is a high-performance, highly available LDAP and REST directory server evolved from the OpenDJ project. While it is fully LDAP v3 compliant and can serve as a general-purpose directory, several architectural decisions make it significantly different from traditional LDAP servers like OpenLDAP or Microsoft AD LDS:

Multi-master replication — DS uses a conflict-resolution-based multi-master topology. Any node can accept writes simultaneously, and conflicts are resolved using fractional replication algorithms. Traditional LDAP servers typically use single-master with read replicas. This makes DS more suitable for active-active deployments across data centres.

REST LDAP gateway built-in — DS exposes all directory objects over an HTTP/JSON API out of the box (no separate gateway needed). Applications can interact with directory entries using REST calls rather than the LDAP wire protocol, which is useful for lightweight clients and cloud-native integration.

Backend storage — DS uses a pluggable backend storage engine. The default is JE (Berkeley DB Java Edition) for user data and an MVCC (Multi-Version Concurrency Control) model that enables consistent reads during writes. DS also supports an PDB (Persistit Database) backend introduced in later versions.

ForgeRock-specific schema — DS ships with extended schema for ForgeRock platform objects — CTS tokens, AM session attributes, IDM managed user objects, and DS service account credentials. A plain OpenLDAP server does not include these schemas and would require significant customisation to serve the same role.

Native Kubernetes operator — DS includes a Kubernetes operator for cloud-native deployment, health checks, and automatic rolling upgrades, which traditional LDAP servers lack.

ForgeRock Identity Gateway (IG) is a reverse proxy and API gateway that sits between clients and backend applications. Its primary purpose is to enforce OAuth2-based access control, session validation, and protocol transformation for applications that cannot natively integrate with modern identity protocols. It evolved from the OpenIG project and shares the same route-based configuration model.

IG protects legacy applications through several mechanisms:

OAuth2 Token Relay — IG intercepts inbound requests, validates the OAuth2 bearer token against AM's introspection endpoint or by verifying the JWT signature locally, and then either passes the request through or forwards user identity information to the backend via HTTP headers. The legacy app never sees the OAuth2 token — it just receives trusted headers like X-Forwarded-User or a custom header with the user's roles.

Login Form Replay — For very old applications with HTML login forms and no API, IG can capture credentials from a modern SAML or OAuth2 login flow and replay them into the legacy form — essentially driving the form submission on behalf of the user. This enables SSO for applications that cannot be modified.

SAML 2.0 Federation — IG can act as a SAML Service Provider in front of a backend application, consuming SAML assertions from AM and translating them into the backend application's expected format (headers, cookies, or request attributes).

Session Injection — IG can request a session from AM on behalf of a user and inject a session cookie into the response, making the backend application believe the user authenticated directly with it.

IG's configuration is JSON-based and consists of Routes (URL pattern matchers) and Filter Chains (ordered sequences of handlers and filters). This declarative model makes IG configuration fully scriptable and GitOps-friendly.

Authentication Nodes are the individual building blocks of Authentication Trees (Journeys) in ForgeRock AM. Each node encapsulates a single, discrete authentication or decision task. It accepts shared state (a map of context attributes), performs its operation, and emits one of its defined outcome paths, which connects to the next node in the graph. Nodes are stateless in themselves — all shared context travels in the shared state map.

ForgeRock ships dozens of built-in nodes. Commonly used ones include:

Custom nodes can be developed as OSGi bundles deployed to AM. This is a common requirement in enterprise projects where vendor-specific requirements (e.g., validating against an internal risk score API or decrypting a proprietary SSO cookie) need to be expressed as first-class tree nodes rather than scripts.

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. Where OAuth 2.0 only answers the question "what can this application access?", OIDC additionally answers "who is the logged-in user?" ForgeRock AM acts as an OIDC Provider (OP), issuing ID tokens that carry authenticated user identity claims in addition to OAuth2 access tokens.

The practical differences in ForgeRock AM's context:

• ID Token — OIDC adds a signed JWT (the ID token) to the token response. It contains claims like sub (subject/user ID), iss (issuer), aud (audience/client), iat (issued at), and exp (expiry). OAuth2 access tokens carry no standardised identity claims.
• UserInfo Endpoint — AM exposes /oauth2/userinfo per realm. Clients send the access token and receive a JSON object with the user's profile claims. This is an OIDC standard; plain OAuth2 has no equivalent.
• Discovery Document — OIDC providers publish a /.well-known/openid-configuration endpoint describing all their supported flows, endpoints, and signing algorithms. AM publishes this automatically per realm.
• Scopes — OIDC defines standard scopes: openid (required), profile, email, address, phone. Requesting openid is what triggers OIDC behaviour; without it you get plain OAuth2.

In ForgeRock AM, OIDC is enabled at the OAuth2 provider level within a realm. The same OAuth2 provider configuration serves both OAuth2 and OIDC — OIDC is activated simply by the client requesting the openid scope. AM supports session management extensions (check_session_iframe, end_session_endpoint) for RP-initiated logout.

SAML 2.0 (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). ForgeRock AM supports SAML 2.0 as both IdP and SP, making it suitable for B2B federation, connecting enterprise applications, and participating in identity federations like InCommon or eIDAS.

In a SAML 2.0 flow where AM acts as IdP:

1. User accesses the SP (e.g., Salesforce, ServiceNow).
2. SP sends an AuthnRequest to AM's SSO service endpoint.
3. AM authenticates the user (via an authentication tree).
4. AM issues a signed SAML Assertion containing the user's identity attributes.
5. AM POSTs the assertion (wrapped in a SAMLResponse) to the SP's Assertion Consumer Service (ACS) URL.
6. SP validates the signature using AM's public key from its metadata and creates a session.

Configuring a Service Provider in AM (IdP-side circle of trust):

• Obtain the SP's SAML2 metadata XML — contains entityID, ACS URL, signing certificates, and name ID formats.
• In AM console, navigate to the realm → Federation → Entity Providers → Import Entity. Paste or upload the metadata XML.
• Create or add to a Circle of Trust (CoT) that includes both the AM IdP entity and the imported SP entity.
• Configure the SP's attribute mapping — define which AM user attributes map to which SAML attributes in the assertion.
• Optionally configure the name ID format — persistent, transient, or email address.

For AM acting as SP (consuming assertions from an external IdP like Azure AD or Okta), the process is reversed — you import the IdP's metadata and configure how incoming assertions are mapped to AM session attributes.

ForgeRock AM's policy engine provides fine-grained authorization (FGAC) — the ability to define rules that control which subjects can perform which actions on which resources, and under what conditions. This is distinct from authentication (proving who you are); policies govern what you are allowed to do once authenticated.

The policy model has three key components:

Policy Set (Application) — A container that groups related policies. Each policy set defines the resource type patterns it governs (e.g., URL patterns for web applications) and the actions that can be controlled (e.g., GET, POST, DELETE). Before creating individual policies, you must have a policy set that covers the resource type in question. AM ships with default policy sets for web agents (URL-based), OAuth2 scopes, and others.

Policy — An individual rule within a policy set. A policy specifies:

• Resources — URL patterns or resource identifiers the policy applies to (e.g., https://app.example.com/api/*)
• Actions — HTTP methods or custom actions and whether they are allowed or denied
• Subjects — Who the policy applies to (authenticated users, specific groups, OAuth2 clients)
• Conditions — Environmental or contextual constraints (IP range, time of day, authentication level, device trust)
• Response Attributes — Additional attributes injected into the policy response that agents can use (e.g., user roles to pass as headers)

Policy Decision Point (PDP) vs Policy Enforcement Point (PEP) — AM acts as the PDP — it evaluates policies and returns decisions. Java agents, web agents, and IG act as PEPs — they intercept requests, call AM's policy endpoint, and enforce the decision by allowing or denying the request.

Policies are evaluated using AM's REST API: POST /json/policies?_action=evaluate. IG filters and AM Web/Java agents call this endpoint transparently on every protected request.

Java Agents and Web Agents are Policy Enforcement Points (PEPs) that integrate directly with application servers and web servers to enforce ForgeRock AM authentication and authorization decisions without requiring changes to the application code.

Java Agent — Installed as a Java EE filter (a JVM-level agent using the -javaagent JVM argument or a servlet filter JAR) on application servers like Tomcat, JBoss, WebLogic, and WebSphere. It intercepts HTTP requests before they reach the application, validates the AM session cookie (iPlanetDirectoryPro by default), and calls AM's policy evaluation endpoint for protected resources. If the session is invalid or policy denies access, the agent redirects the user to AM for authentication.

Web Agent — Installed as a native module on web servers such as Apache HTTP Server, NGINX, and Microsoft IIS. It operates at the web server level — requests are filtered before any proxying to backend application servers. Web agents support the same session validation, policy evaluation, and SSO enforcement as Java agents but are implemented as native C/C++ modules matching the web server's plugin API.

Both agent types share a common configuration model stored in AM:

• Each agent has a profile in AM (under realm → Applications → Agents) with settings for the protected URL list, login URL, logout URL, not-enforced URLs, and header injection rules.
• Agents fetch their configuration from AM at startup and periodically refresh it — changes to the agent profile in AM propagate to running agents without restart.
• Agent communication with AM uses a dedicated agent credentials (username/password) that the agent uses to authenticate and retrieve policies.

For Kubernetes and microservices environments, IG has largely superseded agents since it is more cloud-native and does not require access to the application server's classpath or web server's module directory.

ForgeRock AM implements MFA through its Authentication Trees (Journeys). Rather than configuring MFA as a flag, you compose a tree that explicitly collects a first factor (typically username + password), makes a routing decision (risk score, user enrollment status, IP check), and then presents a second-factor challenge if required. This compositional model makes MFA more flexible than traditional module-based MFA.

Supported second factors in AM:

• OATH TOTP / HOTP — Time-based (Google Authenticator, Authy) or counter-based OTPs using the OATH Token Verifier node. Requires prior enrollment via the OATH Registration node.
• Push Notification — Approve/deny push to the ForgeRock Authenticator mobile app. Uses the Push Sender node to dispatch the challenge and Push Result Verifier to wait for the response.
• WebAuthn (FIDO2) — Hardware security keys (YubiKey) or biometric platform authenticators (Touch ID, Face ID, Windows Hello). Uses WebAuthn Registration and Authentication nodes.
• Email OTP / SMS OTP — One-time codes sent to a registered email address or phone number using OTP Email Sender / OTP SMS Sender nodes.
• Backup Codes — Pre-generated single-use codes for account recovery.

A typical adaptive MFA tree design:

1. Collect username → look up user in identity store.
2. Evaluate risk (IP reputation, device fingerprint, geolocation).
3. If risk is low → single-factor success.
4. If risk is medium → prompt for TOTP.
5. If risk is high or unrecognised device → push notification approval.

Step-up authentication is a variant where a user with an existing low-assurance session is asked to re-authenticate with a second factor to access a sensitive resource. AM supports this via policy conditions that check the AuthLevel of the current session.

Social Authentication in ForgeRock AM allows users to log in using accounts from external identity providers — Google, Apple, Facebook, Twitter/X, LinkedIn, GitHub, and others — without creating a new credential in AM's own directory. AM acts as an OAuth2/OIDC relying party to the social provider and maps the received identity claims into its own user session.

The flow for a typical Google login via AM:

1. User selects "Sign in with Google" on the AM login page.
2. AM redirects the user to Google's authorization endpoint with AM's OAuth2 client credentials and a state parameter.
3. User authenticates to Google and consents to sharing profile data.
4. Google redirects back to AM's callback URL with an authorization code.
5. AM exchanges the code for tokens at Google's token endpoint.
6. AM calls Google's UserInfo endpoint to retrieve the user's profile (sub, email, name).
7. The Social Provider Handler node in the AM authentication tree processes the profile.
8. The Provision Dynamic Account node creates a transient or persistent user profile in AM's identity store.
9. AM creates a session and returns the session cookie to the user's browser.

Configuration in AM involves:

• Registering AM as an OAuth2 application with the social provider (obtaining client ID + secret).
• Creating an Identity Provider configuration in AM for the social provider (AM 6.5+ uses the Social Identity Provider Service, earlier versions used the Social Authentication module).
• Building an authentication tree that includes the Social Provider Handler and an account provisioning/resolution node.

For JIT (Just-In-Time) provisioning, AM can automatically create a user account in DS the first time a social user logs in, using attributes from the social profile. For existing enterprise users, a profile lookup and linking step maps the social identity to an existing account.

ForgeRock AM supports server-side scripting at multiple points in its processing pipeline, allowing administrators and developers to customise authentication, authorization, and OIDC behaviour without modifying AM's source code. Scripts run in a sandboxed environment with a restricted API surface — they can access AM's shared state, make HTTP calls to external services, query the identity store, and manipulate tokens, but they cannot perform arbitrary JVM operations.

Supported scripting languages:

• JavaScript (Nashorn) — Runs via the JVM-embedded Nashorn JavaScript engine (Java 8–11). Nashorn was deprecated in Java 11 and removed in Java 15, so AM 7.x migrated to the Rhino engine for JavaScript execution.
• Groovy — Apache Groovy, which runs natively on the JVM. Groovy scripts have access to Java libraries and tend to have better IDE support and compile-time checking than JavaScript for complex logic.

Script types and their contexts:

Scripts are managed in the AM admin console under Realms → Scripts and can be versioned, shared across trees, and validated with a built-in syntax checker. In AM 7.3+, scripts can be tested directly in the console before deployment.

ForgeRock Directory Services (DS) replication is the mechanism by which data written to one DS server is automatically propagated to all other servers in the replication topology. It enables high availability and geographic distribution — applications can connect to any DS node and always read consistent data (given the eventual consistency window).

DS uses a changelog-based multi-master replication model:

1. Every write to a DS node is first recorded in that node's changelog (a persistent, ordered log of operations with sequence numbers called Change Sequence Numbers / CSNs).
2. Each DS node has replication connections to some or all other nodes in the topology. In larger deployments, a hub-and-spoke topology is used where dedicated replication servers (changelog servers) act as distribution points to reduce full-mesh connection overhead.
3. Nodes exchange changes by streaming their changelogs to connected peers. Each peer acknowledges receipt and applies the change to its local database.
4. Conflict resolution uses CSN ordering — if two nodes receive concurrent updates to the same entry, the change with the higher CSN (based on the timestamp embedded in the CSN) wins. This is a last-write-wins strategy at the attribute level, not the entry level.

In ForgeRock DS 7.x, the replication architecture was significantly simplified — the separate Replication Server component was merged into each DS instance, eliminating the need for dedicated changelog server processes. Each DS instance now serves both directory data and replication changelog, simplifying topology management and reducing the number of JVM processes to maintain.

DS replication status can be monitored with the dsrepl status command, which shows replication lag (in number of missing changes) per server per domain.

Reconciliation in ForgeRock IDM is the process of comparing two populations — a source (typically managed users in IDM's repository) and a target (an external system accessed via a connector) — and taking configured actions to bring them into alignment. It is the batch, on-demand, or scheduled mechanism for ensuring that the two systems represent the same identity population.

During reconciliation, each source object is matched against target objects using a configured correlation query. Based on the comparison result, IDM classifies each record into a situation and takes a corresponding action:

Reconciliation is configured in the sync.json file in IDM's configuration. You define the source and target object sets, the correlation query, a property mapping (which attributes flow from source to target), and the situation-action policy. Reconciliation can be triggered:

• Via the IDM admin UI (Run Reconciliation button)
• Via REST: POST /openidm/recon?_action=recon&mapping=managedUser_systemLdapAccounts
• On a schedule configured in scheduler.json

Managed Objects are the identity entities that ForgeRock IDM owns and governs in its internal repository. Unlike System Objects (which are projections of data from external systems via connectors), Managed Objects are the canonical, authoritative representation of an identity within IDM. IDM persists them in its embedded database (OrientDB in older versions, or an external relational DB like PostgreSQL/MySQL in production deployments).

The most common managed objects in a typical deployment:

• Managed User (managed/user) — The core user identity object. Contains profile attributes (name, email, mobile), entitlement relationships (roles, assignments), account status, and password.
• Managed Role (managed/role) — Groups users and defines what entitlements (assignments) members receive. Roles can be static (explicit membership) or dynamic (membership determined by a query on user attributes).
• Managed Assignment (managed/assignment) — Defines what is provisioned to a target system when a user holds a role. For example, an "Employee" role might include an assignment that creates an LDAP account with specific group memberships.
• Managed Organisation / Group — Hierarchical organisational units for multi-tenant or enterprise deployments.

Managed object schemas are defined in managed.json. Each object type defines its properties, their types, validation rules, and encryption requirements. Password fields are automatically hashed using a configurable algorithm (PBKDF2, bcrypt, SHA-256). You can extend the schema by adding custom properties without modifying IDM's core — just edit managed.json.

All managed objects are accessible via IDM's REST API using the /openidm/managed endpoint: GET /openidm/managed/user?_queryFilter=userName eq "jdoe".

Session management in ForgeRock AM refers to the lifecycle of the authentication state a user establishes after successfully completing an authentication tree. When a user authenticates, AM creates a session and returns a session token to the client (typically as a cookie named iPlanetDirectoryPro). Subsequent requests from that client include the token, and AM validates it to grant access without re-authentication.

AM supports two distinct session types:

Stateful Sessions (CTS-backed) — The session record is stored in the Core Token Service (backed by DS). The session token (SSOToken) is an opaque identifier that references this server-side record. AM must query CTS on every validation call to retrieve session properties. Stateful sessions support rich server-side state — you can store arbitrary attributes in the session, modify them during the session lifetime, and rely on idle timeout (reset on activity) vs maximum timeout (hard ceiling). These sessions participate in cross-realm SSO via the session service.

Stateless Sessions (JWT-based) — The entire session state is encoded in a signed (and optionally encrypted) JWT. No server-side storage is needed; AM validates the session by verifying the JWT signature. This scales better horizontally — any AM node can validate any session without a CTS lookup. The trade-off is that stateless sessions have fixed expiry baked into the JWT and cannot have their attributes modified after issuance. Idle timeout is approximate (based on a rolling JWT issuance) rather than exact.

Session lifecycle operations:

• Validate — Check if a session token is still valid.
• Get — Retrieve session properties (user DN, auth level, etc.).
• Logout — Invalidate the session (stateful: remove CTS record; stateless: add token ID to a blocklist).
• Refresh — Reset the idle timeout on a stateful session.

PKCE stands for Proof Key for Code Exchange (RFC 7636). It is a security extension to the OAuth 2.0 Authorization Code flow that protects against the authorization code interception attack — a threat where a malicious app on the same device intercepts the authorization code before the legitimate application can exchange it for a token.

The attack is possible because, on mobile and desktop platforms, multiple apps can register for the same custom URI scheme (e.g., myapp://callback). When AM redirects back after authentication, any app registered for that scheme can receive the code. Without PKCE, the malicious app could exchange the stolen code for tokens.

PKCE adds a cryptographic challenge/verifier pair to the flow:

1. The client generates a cryptographically random code verifier (a high-entropy string).
2. The client computes a code challenge by hashing the verifier with SHA-256 (S256 method) and base64url-encoding it.
3. The client sends the code_challenge and code_challenge_method=S256 in the authorization request to AM.
4. AM stores the challenge with the authorization code in CTS.
5. When the client exchanges the code, it sends the original code_verifier.
6. AM hashes the verifier and compares it against the stored challenge. They must match for the exchange to succeed.

A malicious app that intercepts only the authorization code cannot complete the exchange because it does not know the original code verifier. In ForgeRock AM, PKCE can be enforced on a per-client basis. For AM 7.x, PKCE is mandatory by default for public clients (those without a client secret) and strongly recommended for all Authorization Code flows. This aligns with OAuth 2.1's direction of making PKCE universally required.

ForgeRock Identity Cloud, now branded as PingOne Advanced Identity Cloud, is ForgeRock's fully managed SaaS IAM platform. It provides the same core ForgeRock capabilities — Access Management (AM), Identity Management (IDM), and Directory Services (DS) — delivered as a cloud-native, multi-tenant service hosted by ForgeRock/Ping Identity on AWS. Customers access the platform without managing the underlying infrastructure, patching, scaling, or upgrades.

Key differences between Identity Cloud and self-managed ForgeRock Server:

Identity Cloud uses an environment model — each customer gets Dev, UAT, and Prod tenants. Configuration changes (journeys, scripts, OAuth2 clients) are promoted between environments using a CICD pipeline-friendly configuration export/import mechanism. IG, if used, is deployed by the customer and configured to point its OAuth2 validation at the cloud AM endpoints.

User Managed Access (UMA) is an OAuth 2.0-based access control protocol (standardised as UMA 2.0 by the Kantara Initiative) that enables a resource owner — a regular end user — to control who can access their resources (data, APIs, documents) and under what conditions, without involving the resource owner in every access transaction. ForgeRock AM implements UMA as an extension to its OAuth2 Authorization Server.

UMA introduces three actors beyond standard OAuth2:

• Resource Owner (RO) — The user whose resources are being protected. They register resources and grant access to specific parties.
• Resource Server (RS) — The server hosting the protected resources. It calls AM to validate Requesting Party Tokens.
• Requesting Party (RqP) — The entity (user or application) trying to access the resource on behalf of someone else.

The UMA flow in ForgeRock AM:

1. The Resource Owner registers their resource with AM's Resource Registration Endpoint, obtaining a resource ID.
2. The RO sets permissions — who (which client or user) can access the resource and under what scopes.
3. A Requesting Party client attempts to access the resource at the Resource Server.
4. The RS checks for a Requesting Party Token (RPT) — if absent, it obtains a Permission Ticket from AM.
5. The Requesting Party exchanges the Permission Ticket at AM's token endpoint, triggering an authorization interaction (possibly requiring RO approval).
6. AM issues an RPT if the RO's permissions allow it.
7. The RS validates the RPT with AM and grants access.

UMA is used in healthcare (patients sharing medical records with providers), financial services (sharing account data with third-party apps), and any scenario where end users need delegated sharing control rather than having an administrator grant access.

Adaptive authentication (also called risk-based authentication) in ForgeRock AM is the practice of adjusting the authentication challenge based on real-time contextual risk signals. Instead of requiring every user to pass a fixed MFA challenge, AM evaluates risk factors and demands a stronger proof of identity only when the risk profile warrants it. This balances security with user experience — low-risk logins get a frictionless single-factor experience; high-risk logins are challenged with MFA.

Risk signals that AM can evaluate natively include:

• Device Fingerprint — Collects browser characteristics (user agent, screen resolution, timezone, plugins) and compares against a stored fingerprint for that user. A new or unrecognised device triggers a challenge.
• IP Address / Geolocation — AM can check the originating IP against a blocklist, whitelist, or GeoIP database. Logins from unexpected countries or IP ranges increase the risk score.
• Previous Session Data — Comparing current login time/location against historical patterns.
• Authentication Level — The tree can check whether the current session already has a sufficient auth level before demanding re-authentication.
• Scripted Risk Scores — Custom Scripted Decision Nodes can call external fraud/risk APIs (such as ForgeRock Intelligent Access, ThreatMetrix, or in-house systems) and route based on the returned score.

A typical adaptive tree flow:

1. Collect username and password → Data Store Decision node.
2. Collect device fingerprint → compare against stored fingerprint.
3. If fingerprint matches → check IP reputation via scripted node.
4. If IP is clean and fingerprint matches → grant access (single factor).
5. If device is new or IP is suspicious → route to TOTP or Push MFA node.
6. If high risk (blocked IP, impossible travel) → deny or require additional verification.

ForgeRock Autonomous Identity (AI-driven) is a separate analytical product in the ForgeRock portfolio that uses machine learning to analyse identity data and access patterns to support identity governance decisions. It was designed to solve one of the most persistent problems in identity governance: role explosion and entitlement sprawl in large enterprises where thousands of roles and permissions have accumulated over years with little coherent rationale.

Autonomous Identity performs three main functions:

Role Mining — The system analyses existing user-entitlement assignments across connected systems (Active Directory groups, application roles, cloud entitlements) and uses clustering algorithms to identify natural role patterns. Instead of manually designing roles from scratch, administrators get AI-suggested roles based on what users actually have in common.

Access Risk Scoring — Each user-entitlement assignment is scored for risk based on how unusual it is compared to peers with similar job functions, locations, and organisation units. A software developer with read access to the financial ledger would receive a high risk score because it diverges from the peer group norm. This enables risk-based access reviews where reviewers prioritise high-score anomalies rather than reviewing every assignment.

Access Certification / Campaign Insights — During access review campaigns (typically run in ForgeRock IDM's governance module), Autonomous Identity provides certification recommendations — should this access be approved or revoked? — based on the risk score and historical certification decisions for similar assignments.

Autonomous Identity is typically deployed as a separate analytics cluster (Apache Spark-based) that ingests identity data via connectors and produces recommendations consumed by IDM's governance workflows. In the PingOne era, these capabilities are being integrated more tightly into the core platform.

Authentication Level and Authentication Context Class Reference (ACR) are two related but distinct ways ForgeRock AM classifies the strength of an authentication event. Both are recorded in the session and in tokens, and both can be used in access policies and step-up authentication flows. They come from different standardisation traditions.

Authentication Level (AuthLevel) is ForgeRock AM's proprietary numeric scale for measuring authentication strength. Each authentication tree or legacy module is assigned a numeric level. A password-only login might be level 1; TOTP adds another level to reach 2; a hardware key might assign level 3. When an application requests a protected resource, the policy condition can require AuthLevel >= 2, triggering step-up if the current session only has level 1. AuthLevel is a coarse integer scale that AM has used since the OpenAM days.

Authentication Context (acr) is the standardised OAuth2/OIDC mechanism for expressing the same concept. The acr (Authentication Context Class Reference) claim in an ID token is a string that describes the authentication method used — for example urn:mace:incommon:iap:silver or a custom string like urn:example:mfa. Applications can request a specific ACR value via the acr_values parameter in the authorization request, and ForgeRock AM will use the appropriate authentication tree mapped to that ACR value.

In ForgeRock AM, ACR values are mapped to authentication trees in the OAuth2 provider configuration. When a client sends acr_values=urn:example:mfa, AM runs the tree mapped to that ACR value and returns the achieved acr in the ID token. This is the OIDC-standard way of expressing step-up requirements and is preferred for interoperable applications over the proprietary AuthLevel mechanism.

Token Exchange (RFC 8693) is an OAuth 2.0 extension grant type that allows a client to exchange one security token for a different one with different properties — different subject, different scopes, different lifetime, or a different format. ForgeRock AM 7.x supports the Token Exchange grant natively, enabling delegation and impersonation patterns that are common in microservices architectures.

The Token Exchange grant type uses urn:ietf:params:oauth:grant-type:token-exchange as the grant type value. Key parameters:

• subject_token — The token being exchanged (access token, ID token, or SAML assertion).
• subject_token_type — The type of the subject token (e.g., urn:ietf:params:oauth:token-type:access_token).
• requested_token_type — The type of token desired in return.
• actor_token — (Optional) The identity of the intermediate service requesting the exchange on behalf of a subject — used for delegation scenarios.

Two key patterns enabled by Token Exchange:

Delegation — Service A calls Service B on behalf of User X. Service A has its own token but needs a token that represents "Service A acting on behalf of User X". Service A exchanges its token plus a subject token (User X's token) and receives a composite token with both identities. The resulting token's act claim contains the actor (Service A's client ID) and the sub is User X.

Impersonation — A trusted back-office service needs to act as another user for administrative purposes. It exchanges its own high-privilege token for a token representing the target user's identity. This requires explicit trust configuration in AM — the requesting client must be granted impersonation rights to prevent abuse.

ForgeRock Identity Gateway (IG) is configured through a route-based model. Every inbound HTTP request is matched against a set of Routes, and the first matching route's handler chain processes the request. Routes are defined as JSON files (or via the Studio UI) stored in IG's configuration directory at ~/.openig/config/routes/.

A Route consists of:

• Condition — A boolean expression using IG's expression language that determines whether this route applies to the request. For example: ${matches(request.uri.path, '^/api/')} matches any request path starting with /api/.
• Handler — The processing chain that runs if the condition matches. This is typically a Chain handler containing an ordered list of filters followed by a final handler that forwards the request to the backend.
• Name — A unique identifier for the route, also used as the filename.

A minimal example route that validates an OAuth2 token and forwards to the backend:

{
  "name": "api-protection",
  "condition": "${matches(request.uri.path, '^/api/')}",
  "handler": {
    "type": "Chain",
    "config": {
      "filters": [
        {
          "type": "OAuth2ResourceServerFilter",
          "config": {
            "introspectionEndpoint": "https://am.example.com/oauth2/introspect",
            "clientId": "ig-client",
            "clientSecret": "changeit"
          }
        }
      ],
      "handler": "ReverseProxyHandler"
    }
  }
}

IG evaluates routes in filename order (alphabetical) and stops at the first match. A default catch-all route should be placed last to handle unmatched requests. Routes can be hot-reloaded — IG monitors the routes directory for file changes and reloads affected routes without restart, enabling live configuration updates in production.

ForgeRock IDM provides a comprehensive password policy engine for managing password requirements on Managed User objects. Unlike AM's authentication-time password validation, IDM's policies govern the passwords stored in IDM's managed repository — enforcing rules at account creation, self-service password reset, and administrator password change operations.

IDM password policies are configured in the authentication.json and managed.json configuration files and enforce rules such as:

• Minimum/maximum length — Password must be between N and M characters.
• Character class requirements — Must contain uppercase letters, lowercase letters, numbers, and/or special characters, with configurable minimum counts per class.
• Disallowed values — Password cannot match the user's own name, email, or username (attribute-based exclusions).
• Password history — Cannot reuse the last N passwords, enforced using stored password hashes.
• Dictionary check — Integration with a configurable word list to reject common passwords.
• Minimum age — User cannot change their password again until N hours/days have passed.
• Maximum age — Password expires after N days; IDM tracks expiry and triggers account lockout or forced password change workflows.

IDM stores passwords using configurable hashing algorithms — PBKDF2, bcrypt, SHA-256, or MD5 (the latter not recommended). The default is PBKDF2 with a configurable iteration count. Passwords are never returned via IDM REST APIs; they can only be set, updated, or validated.

When IDM is integrated with AM and DS, AM's authentication trees call DS for password validation. IDM's password policy applies at write time (registration, reset), while DS enforces its own LDAP password policy at authentication time. Keeping these in sync — especially regarding lockout thresholds — is an important configuration concern in integrated deployments.

The ForgeRock Cloud Deployment Kit (CDK) is a set of Kubernetes-native tooling, Helm charts, Kustomize overlays, and operator resources that enable automated, repeatable deployment of the ForgeRock Identity Platform (AM, DS, IDM, and IG) on Kubernetes clusters. It is the reference deployment architecture for teams running the ForgeRock stack on their own Kubernetes infrastructure — whether on-premises (OpenShift, Rancher) or in the cloud (GKE, EKS, AKS).

CDK provides:

• ForgeOps (Kustomize + Helm) — The open-source ForgeOps GitHub repository contains Kustomize profiles and Helm charts for deploying the entire platform stack. It includes pre-built profiles for development (minimal resources), cloud (production-grade) and CDQ (Continuous Delivery Quality) environments.
• DS Kubernetes Operator — A custom Kubernetes operator (CRD-based) that manages DS clusters: creates stateful sets, handles rolling upgrades, performs health checks, and manages replication topology automatically without manual dsconfig commands.
• Skaffold integration — Development workflows use Skaffold to watch for code changes in configuration files, automatically rebuild Docker images, and re-deploy affected components to a local or remote Kubernetes cluster.
• Secrets Management — Integration with Kubernetes secrets and cert-manager for certificate management; optional integration with HashiCorp Vault for external secret storage.
• Config Profiles — Pre-defined configuration overlays for common use cases: CDQ environments, standalone AM, or full platform stack.

CDK has largely replaced the older zip-file-based installation model for Kubernetes deployments. Teams no longer unzip AM and manually configure it; instead they define their configuration as code in the ForgeOps repository and deploy via Helm or Kustomize, achieving GitOps-compatible IAM infrastructure management.

The shift from authentication chains and modules (AM 6.x and earlier) to authentication trees and nodes (AM 6.5+ / 7.x) represents a fundamental redesign of how ForgeRock AM models authentication flows. Understanding the difference is critical in interviews because many enterprise installations are still mid-migration.

Authentication Chains + Modules (6.x legacy model):
A chain is an ordered list of modules, each with an iRequired flag value: REQUIRED, OPTIONAL, REQUISITE, or SUFFICIENT. These flags (borrowed from JAAS) control how failures propagate through the chain. A module is a Java class that performs a single authentication action and returns a Passed/Failed/Incomplete status. The control flow logic is implicit in the flag model — you cannot branch to a completely different module based on a condition, and you cannot easily implement "if password succeeds, skip OTP for this IP range" without customisation.

Authentication Trees + Nodes (7.x / Journeys model):
A tree is a directed graph of nodes. Each node has explicitly named outcome ports. A "Username Collector" node has a single outcome; a "Data Store Decision" node has "True" (success) and "False" (failure) outcomes; a "Scripted Decision" node can have any number of custom named outcomes. The next node in the flow is determined by which outcome path the current node emits. This gives full conditional branching — you can route to different paths based on user type, device, risk score, or any attribute in shared state.

Key practical differences:

• Trees support inner trees (embedding one tree in another); chains cannot be nested.
• Trees have a visual editor in the AM console; chains are text configuration.
• Custom nodes in trees are OSGi bundles; custom modules in chains are JAR files loaded via the classpath.
• Modules have context-aware flag logic; nodes have explicit outcome edges — more verbose but clearer.
• Modules are still supported in AM 7.x for backwards compatibility but receive no new development. Trees are the only supported model for new features like WebAuthn, Push, and Device Fingerprint.