You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Relay the caller's Authorization to the agent when fetching its card (#75)
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>
rootCmd.PersistentFlags().StringVar(&server, "server", "", "Rossoctl API server URI (overrides the current context; default: current context's server)")
0 commit comments