Looked into it, and this is what I see
- ConnectedNativeClientsByUser JMX gauge
- system_views.clients.username
- nodetool clientstats
These are all connection based metrics and not user metrics. With the model
that the request is what defines the user you can’t “fix” these metrics as they
act as counters over connections.
All other places would show the user U1, its just these places that would only
show P1.
What we could do is create “fake” connections that are only a metrics concern.
Right now we do
if (server != null)
clients.addAll(server.getConnectedClients());
So we could do something like this after the server check
if (proxyServer != null)
clients.addAll(proxyServer.getConnectedClients());
And this just lies and says every client seen in the last N minutes (assuming
we want to expire) has 1 connection (return ConnectedClient; though likely need
to refactor). The only thing that this buys us is that we see the “userName”
and “requestCount”, “authenticationMode” (proxied).
So we know what clients touched the cluster and how many requests they made
Jaydeep does this make sense to you?
> On Jul 29, 2026, at 11:07 AM, David Capwell <[email protected]> wrote:
>
> 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
>>>
>
