> I'm concerned about config updates made through JMX not being persistent
> across restarts
Reasonably so yeah. I was thinking along the lines of "change to config that is
persisted in config file", but now that you mention this I don't think we
actually have a precedent for that yet. And the s
On 7/8/2025 8:22 AM, Abe Ratnofsky wrote:
+1 (nb) from me as well. Would be nice to have a reference implementation of
negotiated authentication in the Java driver; I’d happy to collaborate on that.
I'd love some help with the driver[s]. I plan to do at least "an"
implementation in the Java
I've updated the CEP with a lot of your suggestions below.
One thing I'm holding off on is making "requiresAuthentication" a
JMX-controllable ("hot") property. I do like the idea of being able to
enable it without bouncing nodes. However, I'm concerned about config
updates made through JMX not
> ... so that in the future new options could just be keys in the multimap,
> which would not be considered a protocol change? Or placing all the options
> -- current and future -- into the multimap?
The former. Trying to think through defensive postures on the protocol to
prevent future changes
Hi Josh - Thanks for all the feedback: appreciate it. Responses to
specific points interwoven below ...
On 7/9/2025 3:25 AM, Josh McKenzie wrote:
Sorry for the delay in getting to this Joel. This is great work -
really well thought out and put together. I'm a +1 on it; had the
following obse
Sorry for the delay in getting to this Joel. This is great work - really well
thought out and put together. I'm a +1 on it; had the following observations or
questions reviewing the CEP:
Rather than going with a new discretely allowed option to a closed list of
allowable options in STARTUP, wha
Hi Doug - That's an interesting suggestion for a load test: I'll include
something like that in our plans.
You're right about the logic in RoleManager: it should be doing the
right thing with MutualTlsWithPasswordFallbackAuthenticator.
Thanks! -- Joel.
On 7/8/2025 1:52 PM, Doug Rohrer wrote:
Thanks for submitting this, Joel. IMO this will be a valuable addition to
have and would benefit anyone running C* in a multi-cloud, multi-auth
environment (any big enterprise, really). Also echoing the appreciation for
such a detailed CEP!
Cheers,
-Nate
On Fri, Jul 4, 2025 at 6:39 AM Joel Shephe
+1 from me (I think committer +1s are "binding" on CEPs given our previous "how
we do things" conversation, but either way, +1)...
One interesting perf test to think about would be the difference between
negotiated auth with MutualTlsAuthenticator and PasswordAuthenticator and the
combined Mutu
+1 (nb) from me as well. Would be nice to have a reference implementation of
negotiated authentication in the Java driver; I’d happy to collaborate on that.
Really appreciate the amount of detail in this CEP as well, particularly for
migration paths.
—
Abe
Thanks Andy - My hope/expectation is this would significantly reduce the
amount of friction involved when either implementing or migrating to a
new authenticator. I suspect it will benefit more complex environments
too, when a single authenticator isn't ideal for all clients.
At this point, th
Hi Joel,
+1 (nb), I think this is a really good idea and well fleshed our CEP!
The capability to allow the server to support multiple authenticators would
be very useful. CEP-34 added a
'MutualTlsWithPasswordFallbackAuthenticator' for simultaneously supporting
both mTLS and Password authenticati
Erm ... and here's the CEP:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-50%3A+Authentication+Negotiation
(Thanks for the heads up, Abe ...)
-- Joel.
On 6/30/2025 9:37 AM, Joel Shepherd wrote:
Hello - We would like to propose CEP-50: Authentication Negotiation
for adoption by the
Hello - We would like to propose CEP-50: Authentication Negotiation for
adoption by the community: .
This CEP proposes minor changes to the initial handshake protocol
(OPTIONS, SUPPORTED and STARTUP messages) to enable a client to inform
the node of the authenticators supported by the client,
14 matches
Mail list logo
