Identity Brokering — Configuration
There is no configuration. Step 3 of the wizard asks you for nothing, and that's not a placeholder — Identity Brokering genuinely requires no identity setup on your side.
This page covers what that empty step means, what provisioning creates on your behalf, and the one setting that does matter afterwards: who gets access.
This page applies only to connections using the Identity Brokering identity model.
Step 3 — Identity setup
Open Dashboard → Connections → your connection → Onboarding. Step 3 shows:
No extra setup — users sign in via the hub Keycloak realm.
There's no form and no Save button. Move straight to Step 4.
Before you provision
The one prerequisite is Step 2 — Domain verification. Provisioning refuses to run until it passes:
Verify the connection's domain before provisioningTwo methods are offered:
| Method | How it works |
|---|---|
| DNS TXT record | Add the record the wizard shows to your domain's DNS. Allow time to propagate — confirm with dig TXT yourdomain.com before re-checking. |
| Well-known file | Serve the token the wizard gives you at the path it shows. It must return the raw value with a 200 — not a redirect, not an HTML page. |
Step 4 — Provision
Click Provision. LockMCP creates the identity resources this connection needs, each namespaced to your tenant and connection so connections never share identity configuration:
| Resource | Purpose |
|---|---|
| Connection application client | Represents this connection. The browser sign-in flow is enabled — this is what lets Claude Desktop and similar clients complete an interactive login. |
| Gateway client | The internal service identity LockMCP uses when brokering tokens for this connection. |
| Roles | An admin role (mcp-admin) and a standard member role (mcp-user). |
| Claims scope | Adds the user's roles, tenant and permissions to issued tokens, so the data plane can authorize without extra lookups. |
Unlike Token Exchange, no external identity provider is registered — there isn't one.
Browser sign-in being enabled here is the single technical difference that makes Identity Brokering work with desktop AI clients while Token Exchange doesn't. It isn't a setting you configure — it follows from the identity model you picked in Step 1.
Step 5 — Activate
Activation flips the connection live. Until then the data plane won't serve tools for it, even with provisioning complete.
The configuration that does matter: access
With the connection live, the real setup work is deciding who can use it and which tools they can call. That's under Members & Access:
| Task | Where |
|---|---|
| Invite users by email | Members & Access → Members |
| Create roles beyond the two defaults | Members & Access → Roles |
| Choose which published tools a role may call | Tool Catalog, per tool |
A user needs two things to call a tool: a role on this connection, and that role having access to that tool. Published-but-unassigned tools are invisible to non-admin members.
Switching to this model later
Identity model is set per connection, so you can change it in Step 1 and re-run provisioning — useful if you started with Token Exchange and hit the desktop-client limitation.
Switching to Identity Brokering means your users sign in through LockMCP rather than your IdP, so they'll need LockMCP accounts. Invite them under Members & Access before expecting them to connect.
Where to go next
- Auth Flow — what happens on sign-in and on each tool call
- Troubleshooting — when sign-in or tool access misbehaves