Good feedback, ill look into the complexity and get back to this.
> On Jul 28, 2026, at 2:35 PM, Jaydeep Chovatia <[email protected]>
> wrote:
>
> >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]
> <mailto:[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]
>>> <mailto:[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
>>
