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 authentication, primarily as a means to introduce mTLS auth without breaking password auth and also a possible gradual migration to mTLS, but this only works for combining these two particular authenticators, and also creates another authenticator to support. The migration to any new auth strategy would likely involve the need to simultaneously support an existing and new auth provider. I think the approach you describe is well described and should meet this need assuming users use a driver that supports it. In terms of the protocol, utilizing the capabilities of the existing OPTIONS, STARTUP and SUPPORTED messages to communicate what authenticators are supported/should be used is pretty clever as it shouldn't require a protocol version uprev, and hopefully wouldn't be too complicated for a driver to implement. Thanks, Andy On Mon, Jun 30, 2025 at 11:44 AM Joel Shepherd <sheph...@amazon.com> wrote: > 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 community: <link> . > > > > 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, and changes in > > the node's authentication-related areas to enable it to pick its > > preferred authenticator for each client client connection. The CEP > > explains why this approach is proposed, instead of implementing a > > "negotiating authenticator". > > > > Authentication negotiation will make it easier and safer for > > administrators to migrate clusters to stronger authentication > > mechanisms (including switching on authentication for a cluster that > > has been using "allow-all" authentication) without downtime, and to > > support environments where different clients prefer different > > authentication mechanisms (e.g., username and password for ad-hoc > > cqlsh access, mutual TLS for programmatic access, etc.), without > > having to pick a single "lowest common denominator" authenticator for > > all. Additionally, the proposed changes are intended to be backwards > > compatible for both clients and nodes. > > > > Thanks in advance for your time and feedback. Please keep the > > discussion on this mailing list thread. > > > > Thanks! -- Joel. > > > > > > > > >
