>This means all the client metrics will be showing P1 and not U1 Should we make it configurable, since some users may prefer the actual user instead of the proxy for better debugging purposes?
Jaydeep On Mon, Jul 27, 2026 at 3:40 PM David Capwell <[email protected]> wrote: > Thanks for taking a look! > > Today, one TCP connection → one ClientState → one AuthenticatedUser for > the connection's lifetime, shared across all concurrently in-flight > requests (multiplexed by stream ID). With the proposal, a single connection > can carry concurrent requests for different target identities. Is the > target identity resolved per-request without ever mutating the shared > ClientState, or could two concurrent requests race and cross-contaminate > each other's effective identity? > > > Very good question! The TCP user will be the proxy user (say P1). We > detect that the request is for user U1 and then do something like this > > QueryState qstate = connection.validateNewMessage(request.type, > connection.getVersion()); > if (isProxyRequest(request)) { > var proxiedUser = extractProxiedUser(request); > var rejection = validateProxyAllowed(qstate, request, > proxiedUser); > if (rejection != null) return rejection; > qstate = qstate.proxied(proxiedUser); // This request switched > away from P1 to U1 (proxied by P1) > } > > Message.logger.trace("Received: {}, v={}", request, > connection.getVersion()); > connection.requests.inc(); > Message.Response response = request.execute(qstate, requestTime); > > This means all the client metrics will be showing P1 and not U1; these > are the only places that reach into the connection’s user, the rest of the > code passes around QueryState or ClientState > > On Jul 24, 2026, at 6:48 PM, Jaydeep Chovatia <[email protected]> > wrote: > > Overall, the proposal looks good. I have the following > implementation-related question: > Today, one TCP connection → one ClientState → one AuthenticatedUser for > the connection's lifetime, shared across all concurrently in-flight > requests (multiplexed by stream ID). With the proposal, a single connection > can carry concurrent requests for different target identities. Is the > target identity resolved per-request without ever mutating the shared > ClientState, or could two concurrent requests race and cross-contaminate > each other's effective identity? > > Jaydeep > > On Fri, Jul 24, 2026 at 2:38 PM David Capwell <[email protected]> wrote: > >> Hi everyone, >> >> We'd like to propose CEP-64: Proxy Execution Support [1] for adoption >> by the community. This feature adds a new PROXY permission to >> Cassandra which allows operators to give permission to impersonate >> different users. >> >> Proxy architectures are now a standard part of modern Cassandra >> deployments, yet today they force operators into an unacceptable >> choice: forward raw end-user credentials (creating leakage risk and >> breaking with mTLS/SSO), or collapse everyone into a single service >> account (losing per-user authorization and meaningful audit trails). >> Neither option supports production requirements for both a proxy layer >> and genuine per-user access control. >> >> This CEP closes that gap by letting a trusted proxy role execute >> requests on behalf of specific end-users, with Cassandra enforcing the >> target user's permissions and recording both the proxy and >> effective-user identities. The result is the operational benefits of >> proxies — simplified connectivity, topology hiding, transparent >> migrations — without sacrificing security or auditability. >> >> The CEP is linked here: >> >> https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/440305049/CEP-64+Proxy+Execution+Support >> >> Looking forward to the discussion of this CEP here on the dev list. >> >> Thanks! >> >> [1] >> https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/440305049/CEP-64+Proxy+Execution+Support >> > >
