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]
> <mailto:[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
