将Keycloak Realm配置为另一Keycloak Realm的身份提供商：Realm1作客户端注册域、Realm2作用户池的可行性及教程咨询

Absolutely, this setup is totally feasible and actually a common pattern for separating concerns in Keycloak! It’s a smart way to split client management (Realm1) from centralized user identity data (Realm2)—boosting security (client admins in Realm1 won’t have access to sensitive user pool data) and making future scaling easier (you can reuse Realm2 for other business realms later).

There are two mainstream ways to implement this, depending on your exact needs:

Option 1: Federated User Storage (Realm1 directly pulls users from Realm2) #

This approach lets Realm1 read and use user data from Realm2 directly. When users log into Realm1’s clients, authentication is handled against Realm2’s user pool.

• First, set up Realm2 (your user pool)

  1. Log into your Keycloak admin console, create Realm2, and add all your users and base roles (like user or admin) here.
  2. Create a service account client in Realm2:
     • Go to Realm2’s Clients page, click Create, enter a client ID (e.g., realm1-user-federation), and save.
     • Switch to the Settings tab: set Access Type to confidential and enable Service Accounts Enabled.
     • Go to Service Account Roles: add permissions like view-users, query-users, and impersonation (if you need login simulation capabilities), then save.
     • Head to Credentials: copy the generated secret—you’ll need this later.

• Next, configure federated storage in Realm1

  1. Create Realm1, then go to its User Federation page and select Keycloak as the storage type.
  2. Fill in the config details:
     • Name: A custom label (e.g., Realm2-User-Pool)
     • Keycloak URL: Realm2’s base URL (for Keycloak <17: http://localhost:8080/auth/realms/Realm2; for v17+: http://localhost:8080/realms/Realm2—adjust to your actual domain)
     • Client ID: The client ID you created in Realm2 (realm1-user-federation)
     • Client Secret: The secret you copied earlier
     • Validate SSL: Set to false for local testing, true for production
  3. Save the config, then click Synchronize All Users to pull Realm2’s users into Realm1 (or leave it as real-time query if you don’t want local storage).

• Test it out
  Create a test client in Realm1, set up its redirect URI, then log in using a user from Realm2—you should authenticate successfully, with all user data pulling from Realm2.

Option 2: Identity Brokering (Realm1 delegates auth to Realm2) #

This is more of a "delegation" pattern: when users try to log into Realm1’s clients, they’re redirected to Realm2’s login page. Once authenticated, they’re sent back to Realm1.

• First, set up Realm2 as an Identity Provider

  1. In Realm2’s Clients page, create a client (e.g., realm1-broker), set Access Type to confidential, and add a Valid Redirect URI: http://localhost:8080/auth/realms/Realm1/broker/realm2/endpoint* (adjust path for v17+ by removing /auth).
  2. Copy the client’s secret from the Credentials tab—save it for later.

• Next, add Realm2 as an Identity Provider in Realm1

  1. Go to Realm1’s Identity Providers page and select Keycloak as the provider type.
  2. Fill in the config:
     • Alias: A custom name (e.g., Realm2-IdP)
     • Authorization URL: http://localhost:8080/auth/realms/Realm2/protocol/openid-connect/auth (adjust path for v17+)
     • Token URL: http://localhost:8080/auth/realms/Realm2/protocol/openid-connect/token (adjust path for v17+)
     • Client ID: realm1-broker (from Realm2)
     • Client Secret: The secret you copied earlier
     • Enable User Registration: Toggle this on if you want users who register in Realm2 to be automatically synced to Realm1
  3. Save the configuration.

• Test the flow
  Visit your Realm1 client’s login page—you’ll see a "Login with Realm2-IdP" option. Click it, enter a Realm2 user’s credentials, and you’ll be redirected back to the Realm1 client after successful auth.

• Make sure Realm1 and Realm2 can communicate over the network; use HTTPS in production for security.
• Follow the principle of least privilege: only grant necessary permissions to service accounts (e.g., don’t give full admin access to the federation client).
• If you’re using Keycloak 17 or later (Quarkus-based), remember the /auth prefix is removed from all URLs—adjust your config paths accordingly.

内容的提问来源于stack exchange，提问作者George Jose