The orchestrator is its own client so the exchanged token carries azp = the
agent doing the asking. It is granted two optional scopes — the Catalogue
agent's audience, and llm-proxy-audience because it has to reason — and no
domain audience at all. Every mcp-* and *-api scope it could request comes back
Invalid scopes, which is what makes 'the orchestrator holds nothing' a property
of the realm rather than a line in a prompt.
Note for the next client added by hand: CLIENT.DESCRIPTION is varchar(255), and
a longer one crash-loops the import with 'value too long' rather than a
validation message.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every agent has to name this client in the audience scopes it requests, so the
one thing an agent could not avoid naming was the very thing it should know
nothing about. The gateway serving those URLs is replaceable; the contract
should not imply otherwise.
kong-token-exchange-broker becomes token-exchange-broker, same credential, same
behaviour. The rename was rolled out in order — new client alongside the old,
then the callers, then the gateways, then removal — so no call ever hit a realm
that had forgotten the name its caller was still using. Followed through the
client scope, the audience mappers, the fine-grained admin policy
allow-broker-client, and the roles map.
The Vault property keeps the old name. Renaming it there means re-issuing the
value to every gateway holding a copy, for no gain; the ExternalSecret maps it
to KC_SECRET_TOKEN_EXCHANGE_BROKER instead, so everything the cluster can see
is neutral.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The AI gateway's openid-connect plugin requires audience ["llm-proxy"], but no
client or client scope in the realm could mint it, so every OIDC call fell
through to the anonymous consumer and was terminated with 401 "Authentication
required". Adds the bearer-only llm-proxy client, the llm-proxy-audience scope,
and grants it to the catalogue agent.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
configmap-realm.yaml carried fourteen client secrets and five user
passwords in clear, in a tracked file. Five were there from its first
commit; I added the fourteenth yesterday by following the existing pattern
without questioning it. Making this file authoritative on every start did
not increase the exposure, but it did make the file the place those
secrets live for good — and it is inconsistent with the rest of the
estate, where infra-observability and kong-v2 both take theirs from Vault.
Keycloak resolves ${PLACEHOLDER} in a realm import file from the
environment, so the structure stays in git and the values move to Vault at
secrets/keycloak/classic-models-realm, reaching the import container
through External Secrets.
A store of its own, vault-keycloak, rather than reusing vault-kong-v2 or
vault-observability: each carries a policy scoped to its own path, so a
reader for one estate cannot see another's. Widening an existing policy
would have handed Kong's reader every client secret in the realm.
dataFrom.extract pulls the whole path, so adding a client means adding its
secret in Vault with no edit to the ExternalSecret.
Verified after the switch: the import logs "Realm 'classic-models' imported"
under OVERWRITE_EXISTING, and all three credential paths still work — the
broker's client_credentials, librechat with pm-user's password, and the
Catalogue agent's exchange reaching catalog-mcp with 200. Re-checked that
none of the nineteen original values appears anywhere in the file.
Note the values themselves were committed and are in this repo's history.
They are lab credentials behind a private CA with no real data, but they
should be rotated if that ever stops being true.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file is a bootstrap seed, not the live realm. Keycloak starts with
--import-realm under IGNORE_EXISTING and logs "Realm 'classic-models'
already exists. Import skipped", so editing it changes nothing on a
restart and the truth lives in Keycloak's database.
That divergence had already opened, in the direction that hurts: four
authorisations existed only in the running realm, granted through the
admin API while working out which audiences the gateway actually needs.
classic-models-agent-catalogue +catalog-api-audience
+sales-api-audience
+kong-token-exchange-broker-audience
librechat +classic-models-agent-catalogue-audience
Rebuilding the realm from this file would have left the Catalogue agent
with two of its five scopes and no indication why it stopped working.
Compared object by object against the live realm: the inventories already
matched — 21 clients, 38 client scopes, none missing either way — so the
drift was in contents, not in the lists. optionalClientScopes are now
copied back for every client that differed, and a re-comparison reports no
remaining gap.
This closes today's drift; it does not fix the mechanism that allows it.
Keeping a seed honest by hand is the same arrangement the Flux entrypoints
had before they were made self-reconciling, and it will drift again.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
First of the six agents to need an identity. It exchanges the end user's
token for one narrowly-scoped token per MCP server, so `azp` names the
agent while `sub` stays the human — which is what makes the audit trail
able to answer "which agent asked, on whose behalf".
Deliberately narrower than the librechat client it is modelled on:
* no browser flow at all. standardFlowEnabled, implicitFlow and
directAccessGrants are off, because the agent never logs a user in —
it receives an already-issued token over A2A. Any of those three
would be a way to obtain a token it has no business obtaining.
* no service account. It has no standing access of its own; everything
it can reach, it reaches on behalf of a user who asked.
* two optional scopes, mcp-catalog-audience and mcp-sales-audience, and
nothing else. librechat carries all of them because it fronts every
domain; an agent serving the product manager must not be able to mint
a payments token.
Adds classic-models-agent-catalogue-audience, the scope whoever issues
the user's token requests so the agent appears in that token's audience.
Keycloak's Standard Token Exchange refuses otherwise, with "Client is not
within the token audience" — which reads as a permissions problem on the
target rather than a missing audience on the source.
Verified against the running realm: catalog and sales exchange
successfully and return aud=[mcp-catalog] / aud=[mcp-sales] with
azp=classic-models-agent-catalogue, while payments is refused with
invalid_scope. The confinement is enforced by Keycloak, not by the
agent's own restraint.
Note this file is a bootstrap seed, not the live realm: Keycloak starts
with --import-realm under IGNORE_EXISTING and logs "Realm
'classic-models' already exists. Import skipped", so editing it changes
nothing on a restart. The client and scope were created through the admin
API and recorded here so a fresh install matches. That divergence is
worth closing separately.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Stéphane Tailland