Gandalf operator policy, structured step-up redirect, and step-up token fixes

[1linkovdim]

Four related changes to the step-up escalation path. They are separable if you would rather take them one at a time.

1. Gandalf operator policy instead of isAdmin

NetflixGandalfUserAccessService.checkAuthorityForCurrentUser gates the step-up escalation on UserEntity#isAdmin. That flag is resolved once, in UserServiceImpl.makeUser, from the SSO group list at login, and then baked into the jifa JWT — so a membership change does not take effect until the token is reissued, in either direction.

Replaced with isOperator(subject), a per-request gandalf call against ${fc.operatorPolicy}. This is also what the FlameCommander trigger side is moving to, so triggering a heap dump and inspecting one agree on who an operator is.

fc.adminGroup stays as-is; UserServiceImpl still uses it to populate UserEntity#isAdmin.

Requires fc.operatorPolicy in the config (companion change in the wrapper repo, OBS-flamecommander-operators), otherwise the escalation branch denies everyone.

2. Structured redirectUrl instead of words[9]

Analysis.vue recovered the stairmaster URL by splitting the exception message on whitespace and taking index 9. That message is authored by the stairmaster client, so any wording change silently breaks the redirect.

New StepUpRequiredException carries the URL as a field. ErrorUtil.toJson emits it as redirectUrl, and the frontend reads the field.

The scrape still exists, but it now lives in one place (StepUpRequiredException.fromMessage) with a regex rather than a word index, and a TODO to read a real property if a future stairmaster release exposes one.

3. STEP_UP_TOKEN never reached the enforcer on the REST path

checkAuthorityForCurrentUser is called from ReadOnlyFileServiceImpl.getFileByUniqueName, which is reached over REST. Nothing populated STEP_UP_TOKEN on that path — only AnalysisApiStompController set it, and only for STOMP messages. So the header the frontend sent was dropped, and the enforcer saw no token.

New StepUpTokenFilter (OncePerRequestFilter, registered for HTTP_API_PREFIX/* at Integer.MAX_VALUE - 1, i.e. after the security filter chain and before the JWT refresh filter) reads the header, sets the ThreadLocal, and clears it in a finally.

4. Cross-session step-up token leak

StompConfigurer's inbound ChannelInterceptor set STEP_UP_TOKEN from the CONNECT frame. That interceptor runs on a pooled clientInboundChannel thread (corePoolSize = cores * 2), and the ThreadLocal was only cleared when a later, tokenless CONNECT happened to land on the same thread. Between those two events, one user's step-up token was visible to whichever session that thread served next.

Removed the interceptor write entirely. Nothing is lost: the frontend sends the header on every publish (analysis-api-requester.ts), so AnalysisApiStompController reads it per message and clears it in a finally, and the authority check itself runs on the REST path covered by the new filter.

Also documented the remaining boundary in AnalysisApiStompController: its finally clears the token as soon as apiService.invoke returns its future, so async work continuing on another thread does not see it. Nothing depends on that window today.

Not built

I have not compiled this — the gradle build needs internal artifactory, and I could not get stairmaster-enforcement-client-spring locally, so the StepUpConstants usage is unverified against the real jar. Please treat CI as the first real check.

🤖 Generated with Claude Code