Skip to content

Use this page to configure an external OpenID Connect identity provider in the Keycloak Metaco realm.

Before you begin

Prepare the following values from your identity provider:

ValueNotes
Discovery endpointURL ending in .well-known/openid-configuration. Keycloak must be able to reach it.
Client IDStatic client ID reserved for Custody federation.
Client secretSecret for the client ID. Store and rotate it through your standard secret-management process.
Redirect URIKeycloak broker endpoint for the provider alias. Register it with the upstream IdP.
Claim choiceClaim used to identify users, such as sub, email, or another stable claim emitted by the IdP.
Required claimOptional claim that proves the user is assigned to the Custody application in the upstream IdP.
Provider aliasUnique lower-case alias. This must match the Custody loginIds.providerId value.

Configure the identity provider

  1. Log in to the Keycloak Admin Console.
  2. Select the Metaco realm.
  3. Go to Identity providers.
  4. Create a new OpenID Connect provider.
  5. Enter the provider alias, discovery endpoint, client ID, and client secret.
  6. Disable user info if the required claims are already present in the ID token.
  7. In advanced settings, set scopes to request the claims your mappers require, for example openid email profile.
  8. Set First login flow to Harmonize Flow.
  9. If your identity provider requires a mandatory claim for Custody access, configure an essential-claim check.
  10. Save the provider.

The provider alias is not just a display name. It is the value Custody uses as the providerId in user loginIds.

Keep the client secret configured in Keycloak synchronized with the secret configured in the upstream identity provider. If you rotate one side, update and verify the other side during the same change window.

Configure provider mappers

Create the mappers required for stable user linking and downstream token behavior.

MapperPurpose
BROKER_ID Username Template ImporterSets the federated identity lookup key for repeat logins.
BROKER_USERNAME Username Template ImporterSets the broker username used for display and downstream mapping.
Username with provider aliasPrefixes the local Keycloak username with the provider alias to avoid collisions.
Hardcoded user session attributeStores the identity provider alias in the Keycloak user session.

BROKER_ID Username Template Importer

FieldValue
NameBROKER_ID Username Template Importer
Mapper TypeUsername Template Importer
Sync ModeInherit
Template${ALIAS}:${CLAIM.<claim-name>}
TargetBROKER_ID

BROKER_USERNAME Username Template Importer

FieldValue
NameBROKER_USERNAME Username Template Importer
Mapper TypeUsername Template Importer
Sync ModeInherit
Template${ALIAS}:${CLAIM.<claim-name>}
TargetBROKER_USERNAME

Username with provider alias

FieldValue
NameUsername with provider alias
Mapper TypeAppend provider alias to username
Sync ModeForce

Hardcoded user session attribute

FieldValue
NameHardcoded user session attribute
Mapper TypeHardcoded User Session Attribute
Attributeidentity_provider_alias
Attribute ValueYour provider alias
Sync ModeForce

Use : as the separator in username template values, for example ${ALIAS}:${CLAIM.email}. Do not use . as the separator.

Map Custody users to the provider

Each federated user must have a Custody loginIds entry for the provider alias and identifier emitted by the mapper.

{
  "loginIds": [
    {
      "id": "user@example.com",
      "providerId": "corporate-oidc"
    }
  ]
}

Update users through the governed user-management flow. For procedures, see Manage users and roles.

Verify the integration

Before enabling the provider for a wider user group:

  1. Confirm Keycloak can reach the discovery document and JWKS endpoint.
  2. Confirm the upstream IdP returns the claims required by the mapper templates.
  3. Confirm any required or essential claim is present only for users assigned to the Custody application.
  4. Confirm a test user can sign in through Keycloak.
  5. Confirm repeat login reuses the same user instead of creating a duplicate identity.
  6. Confirm the Keycloak-issued token contains the expected subject and audience values.
  7. Confirm Ripple Custody maps the token to the expected user, domain, and roles.
  8. Confirm session and logout behavior matches your requirements.

For common failure modes, see Troubleshoot SSO.