Skip to main content

Federation

Federation connects your realm to a directory such as LDAP/Active Directory so Pony ID can search, authenticate, and optionally synchronize users. In Pony ID (Keycloak), the external directory remains the source of account data, while Pony ID issues the OIDC tokens your applications consume.

If you are weighing approaches, contrast this with Brokering. Brokering trusts another IdP over OIDC/SAML and creates the user record at first login. Federation integrates directly with a directory and can pre-provision or periodically sync users without waiting for first logins.

How federation works​

  1. An admin registers a federation provider (for example, LDAP) in Pony ID.
  2. Users and selected attributes are imported on demand or via a scheduled sync.
  3. On sign-in, Pony ID may authenticate against the directory (depending on the mode) and then issues an OIDC token for the session.

This lets you populate accounts before launch and keep them current over time. Authentication can be delegated to the directory you trust, while tokens and sessions are still managed locally by Pony ID.

Federation and brokering in practice​

Federation connects to a directory (LDAP/AD or a custom user store) and supports bulk or periodic synchronization. Brokering trusts another IdP via OIDC/SAML and only creates the user in Pony ID after the first successful login. With federation, authentication may be delegated to the directory while token issuance remains local to Pony ID; with brokering, the external IdP asserts identity and Pony ID brokers it. Profile data in federation is controlled by federation mappers and sync strategies; in brokering, it is copied during first-login import. See Brokering for details.

When to choose federation​

Choose federation when you need cold-start population of accounts, ongoing lifecycle synchronization from an enterprise directory, or directory-backed authentication while standardizing on OIDC tokens for your applications. Prefer brokering when your organization already centralizes identity in an IdP such as Okta, Azure AD, or Google and bulk import is unnecessary.

How this interacts with the Pony ID Backend​

Regardless of federation or brokering, Pony ID treats the OIDC token issued by Keycloak as the source of user identity. Configure which claim becomes the user_id used in assignments (sub, email, or preferred_username) and, if you include group memberships in tokens, align Pony ID group names with the claim values you emit. For configuration details, see Backend Configuration and Users & Groups.