Integration with Kagenti

[usize]

Problem

Kagenti has a nice Spiffe/Keycloak integration out of the box. It also has a sidecar called "AuthBridge" that handles token exchange (though only supports a single hop's worth of information in its current implementation due to no act claim support).

Putting that all together, we should try deploying a demo in the context of Kagenti.

Basic Demo Story

• Alice/Bob/$USER chats with an A2A agent via Kagenti UI
• AuthBridge exchanges the user's token for one targeting a tool server that handles document access
• The tool server reads act claims from the exchanged JWT and asks OPA whether the intersection of group claims (organization) can access it.

Components that seem necessary

Keycloak

• Users ported to KeyCloak
• KeyCloak clients registered for the A2A agent and the tool server (AuthBridge has a helper script for setting up clients that support token exchange)

Open Questions

How will we support act claims?

KeyCloak doesn't support it now and we may need to vibe code an SPI? That's doable but will require either building our own KeyCloak image to deploy, or mounting a new volume on the KeyCloak container with our own providers directory. Looks like this is also achievable with an init container: bitnami/charts#15930 (just an example of someone with this problem)

We can also SKIP act claims for now. For a single hop we would have the user in the sub claim and the agent identity in the azp claim. This is not using azp as it's intended, but it would allow us to build a working one hop demo without a custom SPI.

A2A Agent

• Calls the tool/document server to fetch documents
• AuthBridge configured to exchange token en route
• Document server returns document content (or denial reason)

Open Questions

How do we deploy AuthBridge?

Perhaps we'll have to roll our own manifest in lieu of using the UI for now? We should verify this with Kagenti folks since webhook registration should also be possible.

Tool/Document Server

• Based on what's already here (can it just be adapted?)

Policies

• Same permission intersection logic, but input comes from JWT claims instead of delegation context objects.

Open Questions

We still need a more robust way of mapping group membership to users and agents. "SpiceDB" type solutions make this relatively easy, with OPA hard coding is okay for a first pass since the main point of this is to show off token exchange + delegation semantics + policy engine.

Acceptance Criteria

• Users managed via KeyCloak.
• Token exchange semantics capture information about which user is talking to our agent.
• The information embedded in the JWT token via token exchange is used to allow/deny access to documents.

[pavelanni]

Implementation plan alignment

We have a detailed refactoring plan in docs/dev/KAGENTI_INTEGRATION_REFACTORING.md (on branch feature/summarizer-auth-removal) that addresses this issue. Here's how the plan maps to the components and open questions raised here.

How the plan addresses the issue

A2A Agent. The plan strips all SPIFFE/mTLS/delegation logic from the summarizer agent binary. The result is an auth-free agent that makes plain GET /documents/{id} calls. The AuthBridge sidecar (deployed via Kustomize overlay) transparently intercepts outbound HTTP, performs Keycloak token exchange, and injects the Authorization: Bearer <token> header. The agent never sees tokens or certificates. This gives us a clean two-stage demo: same binary works without auth (open mode) and with auth (AuthBridge overlay).

Tool/Document Server. The document-service is adapted to support both modes behind the same GET /documents/{id} endpoint. When no JWT is present, it serves documents openly. When a JWT is present (injected by AuthBridge), it validates the token and runs OPA policy evaluation using the claims.

Policies. The permission intersection logic stays in OPA, but the input switches from SPIFFE-based delegation context objects to JWT claims. For the initial single-hop implementation, sub identifies the user and azp identifies the agent — this aligns with our existing ext-proc token exchange implementation without needing a custom Keycloak SPI for act claims.

AuthBridge deployment. The plan uses a Kustomize overlay to add the AuthBridge sidecar to the summarizer pod. The AuthBridge is configured with Keycloak client credentials for the summarizer agent.

Items not in scope for this plan

Keycloak setup. Users are already configured in the remote Keycloak server. No additional Keycloak work is needed in this plan — we use the existing remote Keycloak instance even for local Kind development.

Group membership mapping (SpiceDB). The plan continues using OPA with hardcoded mappings for group-to-user/agent resolution. A SpiceDB-based approach is a natural follow-up but is out of scope for this phase.

Additional work in the plan (not in the issue)

Standalone module extraction. The plan includes extracting the summarizer as a standalone Go module with its own go.mod for contributing to kagenti/agent-examples, avoiding monorepo dependencies.