Relay the caller's Authorization to the agent when fetching its card - #75
Merged
Conversation
GET /chat/{ns}/{name}/agent-card sent no Authorization header to the agent, so
an agent hosted by `authbridge exec` could never have its card fetched: the
inbound pipeline answered the unauthenticated request with 401 and
WWW-Authenticate: Bearer. `agents card` and `agents chat` both failed, and
--with-authorization did not help — that flag attaches the token to the A2A
message, which is sent after the card lookup that was failing.
Confirmed against a live agent by the pipeline's own policy header: the
violation was auth.malformed_header before, meaning no header arrived, and
auth.token_expired after, meaning the relayed token arrived and was parsed. A
stub agent driven through the real command logs the full bearer token.
The header is forwarded verbatim rather than read from the config file. This
handler proxies one request and the caller has already chosen which identity to
present; reading a token from disk would attach a credential to a request that
deliberately carried none, and would make the response depend on state the
caller cannot see. The destination is the instance record's loopback inbound
address, never anything the request controls, which is what makes relaying a
bearer token acceptable here.
The 401 hint was also wrong for this case, naming the one remedy that cannot
work. A 401 the server relayed from an agent now says the credentials were
accepted and that signing in will not help, pointing at the pipeline policy and
the token's audience instead. An unrecognized body still gets the original
sign-in hint, so nothing regresses.
`agents chat` help claimed the card lookup always carries the context's token;
it does not when --server is given.
The weather-service example comments out its spiffe and mtls blocks, since mTLS
requires the SPIFFE block and a local run has no workload API socket.
Assisted by Claude.
Signed-off-by: Ed Snible <snible@us.ibm.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The agent-card endpoint sent no
Authorizationheader to the agent, so an agent hosted byauthbridge execcould never have its card fetched — the inbound pipeline answered the unauthenticated request with 401 andWWW-Authenticate: Bearer.agents cardandagents chatboth failed, and--with-authorizationdid not help: that flag attaches the token to the A2A message, sent only after the card lookup that was failing.Confirmed against a live agent by AuthBridge's own policy header:
The header is forwarded verbatim rather than read from the config file. This handler proxies one request and the caller has already chosen an identity; reading a token from disk would attach a credential to a request that deliberately carried none. The destination is the instance record's loopback inbound address, never request-controlled.
Also fixes the 401 hint, which named the one remedy that cannot work here — a relayed 401 now says the credentials were accepted and signing in will not help, pointing at the pipeline policy and token audience. An unrecognized body still gets the original hint.
Two smaller things:
agents chathelp claimed the card lookup always carries the context's token (untrue with--server), and the weather-service example comments out itsspiffe/mtlsblocks since mTLS needs the SPIFFE block and a local run has no workload API socket.Assisted by Claude.