fix(auth): register the JWK Set endpoint filter - #52
Merged
Conversation
Puts the Hermes dashboard behind estate single sign-on instead of its own password: the session that opens Grafana, Outline and Headlamp now opens Hermes too. Public client with PKCE, the same shape as headlamp and rabbitmq. That is forced rather than chosen -- Hermes' dashboard takes only HERMES_DASHBOARD_OIDC_ISSUER, _CLIENT_ID and _SCOPES, with no field for a client secret, so a confidential client could not authenticate at all. The upside is there is no secret in Vault and none to rotate. The HERMES grant moves rather than disappears. Hermes' route carries no forward-auth -- a middleware there would intercept the OIDC callback and break the login before the dashboard sees the authorization code, which is why outline is `direct` too -- so DOWNSTREAM_CLIENT_PERMISSIONS enforces the grant at the authorize endpoint instead. The redirect URIs are the one coupling worth watching: Hermes builds its callback as <public_url>/auth/callback verbatim from HERMES_DASHBOARD_PUBLIC_URL in fleet-infra. If the two drift the flow fails at the redirect and the dashboard reports only a generic error, so the test pins both spellings.
Vault's OIDC login failed at id_token verification: failed to verify signature: fetching keys oidc: failed to decode keys: expected Content-Type = application/json, got "text/html" ... invalid character '<' looking for beginning of value <!doctype html> The HTML was the auth-ui SPA. /api/oauth2/jwks sat inside the authorization-server filter chain under anyRequest().authenticated(), so an unauthenticated fetch was redirected to /login and served the login page instead of a JWK set. With Accept: application/json the same request answers 401, which is the honest shape of it. JWKS publishes public signing keys. Every relying party fetches it to verify a signature and none of them holds a session, so it has to answer unauthenticated -- the endpoint is public by specification. Confirmed in-cluster through a port-forward, with no ingress and no Cloudflare in the path, so the CDN challenge page in the reported error was incidental rather than causal. The sibling discovery document was never affected because its filter short-circuits before authorization, which is what made this look like a routing or proxy fault. The path is now a constant used both by AuthorizationServerSettings and by the public list, and a test asserts the advertised endpoint is in that list -- a rename that moves one without the other reintroduces the exact outage, and nothing else in the suite would notice. Verified the test fails against an empty list before it passed against the fix. Nothing else in the chain is opened: the test also asserts authorize, token, revoke, introspect and userinfo stay authenticated. Vault's token exchange had already succeeded, so only key retrieval was broken. This was invisible for months because relying parties cache the key set after one successful fetch; it surfaces only on a cache expiry or a restart.
Making the endpoint public (#50) removed the authorization gate but uncovered the real fault beneath it: nothing served the path at all. It now reaches the DispatcherServlet and fails as NoResourceFoundException: No static resource api/oauth2/jwks OAuth2AuthorizationServerConfigurer registers NimbusJwkSetEndpointFilter only when it can resolve a JWKSource. It checks the HttpSecurity shared object first and otherwise looks the bean up by ResolvableType.forClassWithGenerics(JWKSource::class, SecurityContext::class), which does not match the Kotlin `JWKSource<SecurityContext>` bean in JwtConfig. The filter was therefore never added. Passing the bean in as a parameter and setting it as the shared object makes the registration deterministic rather than dependent on generic resolution. Everything else on this chain was unaffected, which is what disguised it: /api/oauth2/authorize answers on its customised path, and the discovery document advertises the customised jwks_uri, so the settings were plainly being applied and only this one filter was missing. Both defects had to be fixed for a relying party to verify a token: with only the first, the endpoint is reachable and returns 500; with only the second, the filter exists but authorization redirects the caller to /login before it runs.
ExtraToast
added
type: bug
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.
Summary
Making the endpoint public (#50) removed the authorization gate and uncovered the real fault beneath it: nothing served the path at all. After that fix,
/api/oauth2/jwksreaches the DispatcherServlet and fails:OAuth2AuthorizationServerConfigurerregistersNimbusJwkSetEndpointFilteronly when it can resolve aJWKSource. It checks theHttpSecurityshared object first, otherwise looking the bean up byResolvableType.forClassWithGenerics(JWKSource::class, SecurityContext::class)— which does not match the KotlinJWKSource<SecurityContext>bean inJwtConfig. The filter was never added.Passing the bean in as a parameter and setting it as the shared object makes registration deterministic instead of dependent on generic resolution.
How it was narrowed
/api/oauth2/authorize→ 401 on its customised pathjwks_uri: …/api/oauth2/jwks/api/oauth2/jwks→NoResourceFoundException/oauth2/jwks(default path) → 401 from the other chainThat combination rules out routing, ingress and Cloudflare, and points at exactly one missing filter.
Both defects were required
/loginbefore it runs.A relying party needs both to verify a token.
Validation
{"keys":[…]}withcontent-type: application/json. I will confirm that against the published URL rather than inferring it from a green build, since the previous fix looked complete and was not.Note
I should have caught this in #50. The 302 had an obvious cause and I stopped at it, rather than confirming the endpoint actually served a key set once the gate was removed — which is exactly the "verify the value, not the command" rule.