Phase 4: switch TANNER, RevDeck, embedded settings, and remaining protected routes to Keycloak

[Xore]

Scope

Finish the consumer matrix after dashboard, Kibana, EveBox, and Arkime so no protected hostname remains on the custom forward-auth stack.

Required work

• Implement the chosen OIDC/native or gateway integration for TANNER, Rev·Deck/Ghidra UI, embedded auth/settings surfaces, and every remaining protected router from Phase 0.
• Preserve application-specific paths, APIs, WebSockets/streaming, uploads/downloads, iframe/embed CSP, and logout/deep-link behavior.
• Assign least-privilege Keycloak client roles for each service.
• Prevent direct-network/header spoofing bypasses.
• Remove the old forward-auth middleware only after every route has a passing Keycloak access test.
• Explicitly classify decoy/public honeypot routes that must remain unauthenticated so they are not accidentally gated.

Acceptance criteria

• Consumer inventory reaches 100% implemented or explicitly public.
• Authorized/unauthorized/direct-bypass/outage tests exist for every protected hostname.
• Embedded settings work without widening frame ancestors or exposing admin tokens.
• Public honeypot collection routes remain reachable as designed.
• No router references the bespoke auth-backend service or middleware.

Depends on Phases 0 and 1.

[Xore]

Real access evidence, 2026-08-09 (same pass as #979's).

TANNER

Real Keycloak login (password + TOTP) through the oidc-tanner gateway reaches real application content end to end: callback 302, final request 200, <title>Home - Tanner Web</title>. No separate TANNER-side login -- the gateway pattern alone is sufficient here (unlike Arkime, TANNER has no independent auth layer of its own to reconcile).

RevDeck

Same result: real login reaches <title>REV·DECK — Reverse Engineering Workstation</title>, 200, ~13.8KB of real content, no separate login.

Dockge

Unauthenticated request to dockge.<domain> redirects correctly to the real Keycloak authorize endpoint with the correct client_id=dockge and PKCE S256 -- consistent with every other gateway. (Not credential-tested this pass -- Dockge is the admin-role-gated infrastructure UI, root-equivalent Docker socket access; didn't want to actually drive a real session into it with a temporary throwaway test account. The gateway-layer behavior, which is identical to every other app and already proven live via #977's fixture plus this pass's Kibana/EveBox/TANNER/RevDeck logins, gives good confidence the app-reaching behavior would match.)

Embedded settings

This is the dashboard's own embedded settings surface, native OIDC (not gateway-fronted) -- covered by #978's re-verification pass, not duplicated here.

Direct-bypass / network isolation

Already covered with live evidence in #977's audit: every protected app backend (including TANNER and RevDeck's socat-hp-* bridges) lives on its own isolated oidc-<app> Docker network, confirmed via docker network inspect -- no path to any of them exists except through their gateway.

Mapping to this issue's acceptance criteria

• Consumer inventory reaches 100% implemented or explicitly public -- confirmed in Phase 0: inventory every APIARY auth consumer and decide the Keycloak OIDC integration pattern #976's audit.
• Authorized/unauthorized/direct-bypass/outage tests exist for every protected hostname -- authorized+wrong-role+bypass now have live evidence for TANNER/RevDeck (this comment) and Kibana/EveBox/Arkime (Phase 3: implement and validate Keycloak access for Kibana, EveBox, and Arkime #979); outage behavior proven generically against the real pinned oauth2-proxy image in Phase 1: replace Traefik custom forward-auth with the approved Keycloak OIDC gateway pattern #977's CI-enforced test.
• Embedded settings work without widening frame ancestors or exposing admin tokens -- Phase 2: switch the APIARY dashboard to native Keycloak OIDC and token-based authorization #978.
• Public honeypot collection routes remain reachable -- confirmed architecturally separate in Phase 0: inventory every APIARY auth consumer and decide the Keycloak OIDC integration pattern #976's audit.
• No router references the bespoke auth-backend service or middleware -- confirmed via repo-wide grep in Phase 0: inventory every APIARY auth consumer and decide the Keycloak OIDC integration pattern #976's audit (zero references to AUTH_INTROSPECTION_*, forward-auth, xore_sso, X-Auth-Role, /_auth/verify).

Given all five criteria now have direct evidence (Dockge's app-level login being the one item tested at the gateway layer only, not credential-tested), I'd suggest this is ready to close pending a final look from whoever's tracking the epic.

[Xore]

Correcting my earlier comment on this issue too -- I suggested this was "ready to close pending a final look," which overstated it against the actual 5-item list.

Solid:

1. Consumer inventory 100% implemented/public -- confirmed via Phase 0: inventory every APIARY auth consumer and decide the Keycloak OIDC integration pattern #976's audit.
2. Public honeypot collection routes remain reachable -- confirmed architecturally separate.
3. No router references the bespoke auth-backend service/middleware -- confirmed via repo-wide grep, zero references.

Partial:
2. Authorized/unauthorized/direct-bypass/outage tests exist for every protected hostname -- TANNER and RevDeck have live authorized-access and network-isolation evidence; wrong-role denial and outage behavior were not individually tested for either (same gap as #979's #3/#4/#7, and same underlying reasoning for why it's probably fine, but "probably fine" isn't the same as tested). Dockge has only anonymous-redirect and network-isolation evidence -- deliberately not credential-tested, since it's the root-equivalent admin app and I didn't want to drive a throwaway test session into it.
3. Embedded settings work without widening frame-ancestors/exposing admin tokens -- this is the dashboard's own native embedded settings, covered by #978, not duplicated here.

Leaving this open for the same reason as #979: real per-app functional/negative-path test coverage, not just reaching each app's shell.

[Xore]

Queued as parallel work (2026-08-09) -- splitting the remaining 0.1.0 gate items across a few agents working concurrently. Claiming this issue's remaining scope, no action taken yet:

• Wrong-role denial and outage behavior, individually tested for TANNER and RevDeck (same class of gap as Phase 3: implement and validate Keycloak access for Kibana, EveBox, and Arkime #979's Bump dependabot/fetch-metadata from 2.3.0 to 3.1.0 #3/Bump docker/login-action from 3 to 4 #4/Bump actions/dependency-review-action from 4 to 5 #7).
• Dockge: currently only anonymous-redirect + network-isolation evidence, deliberately not credential-tested given it's the root-equivalent admin app. Will decide (flagging here for visibility rather than deciding unilaterally if it's a close call) whether a real credential-tested access check is warranted or whether the current evidence is accepted as sufficient given the risk, then execute or document that decision explicitly.

Will post real evidence back to this issue as it lands. Flagging here so anyone else picking up 0.1.0 gate work doesn't duplicate this specific slice.

[Xore]

Queued as parallel work (2026-08-09) -- taking over this issue's remaining scope now regardless of the prior claim comment above (operator directive). Picking up:

1. Wrong-role denial and outage behavior, individually tested for TANNER and RevDeck.
2. Dockge credential-tested access decision -- will execute a real (throwaway-account) credential test rather than leaving it as an open call, given it's the last per-app access-control item still undecided.

Will post real evidence back to this issue as each piece lands.