Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Outgoing strategies differ on no-subject-provider fallback (xaa hard-fails, token_exchange and aws_sts fall back) and it is undocumented

Aperta Adatta ai principianti
  • Qualcosa non va?
#6,177 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

  • #6797 di @suantea — chiusa senza merge

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
go
Ambito
authentication, documentation

Direzione di ricerca

Leggere la documentazione outgoing-auth e confrontarla con pkg/vmcp/auth/strategies/xaa.go:113-119 e aws_sts.go:135-147; esaminare anche l'entry point della strategia token_exchange. Il lavoro è completato quando la documentazione indica chiaramente se ogni strategia richiede un subject provider e cosa accade quando è assente, inclusi i dettagli del fallback di aws_sts.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug

Problem

Three outgoing strategies behave differently when no subject provider is configured, and the
difference is not documented anywhere. Two fall back to the presented token; one hard-fails.

xaa — hard-fails. pkg/vmcp/auth/strategies/xaa.go:113-119:

idToken := identity.UpstreamIDTokens[config.subjectProviderName]
if idToken == "" {
    return fmt.Errorf("provider %q: %w", config.subjectProviderName, authtypes.ErrUpstreamTokenNotFound)
}

No fallback. The stored upstream ID token is populated only by a session-keyed load, so xaa
cannot work from an inbound token alone.

aws_sts — falls back. pkg/vmcp/auth/strategies/aws_sts.go:135-147:

if cfg.SubjectProviderName != "" {
    bearerToken = identity.UpstreamTokens[cfg.SubjectProviderName]
    ...
} else {
    ...
    slog.Debug("aws_sts: SubjectProviderName empty, falling back to identity.Token")
}

token_exchange — falls back. It never reads a subject provider, so it exchanges the
presented token unconditionally.

Why it matters

Two consequences, and the second is the reason to write this down.

Operationally, an operator configuring a deployment where no upstream provider is pinned
gets a working outbound path on two strategies and a runtime failure on the third, with nothing
in the configuration surface signalling which. The xaa failure appears as
ErrUpstreamTokenNotFound naming a provider the operator may not have configured on purpose.

For anything acting on a foreign-issuer token — an agent presenting a delegated token rather
than a browser session — xaa is structurally unavailable, because the stored ID token it needs
is only ever populated by a login flow. token_exchange and aws_sts are the paths that can
work at all. That is worth stating in the strategy documentation rather than being discovered by
whoever tries xaa first.

One related note on aws_sts: its fallback path uses identity.Token, the raw presented token,
and the same strategy reads inbound claims to select which IAM role to assume. So it is the one
strategy where inbound claims are authority-bearing and the presented token is accepted
directly. That combination deserves a sentence in its own docs.

Suggested shape

Document the fallback behaviour per strategy — a short table in the outgoing-auth docs stating,
for each, whether a subject provider is required and what happens when it is absent. Optionally
validate at configuration time so that xaa without a subject provider fails at startup rather
than on the first call.

No behaviour change is being proposed. The strategies may well be right to differ; the point is
that nothing says they do.

Lingua principale
Go
Stelle
2.3k
Fork
318
Merge medio
1g 21h
PR unite (30g)
96

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di stacklok/toolhive

Tutte le issue di stacklok/toolhive

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.