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 Shepherd <sheph...@amazon.com> wrote: > 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, the stickiest bits I've run into have involved logic that > switches on "the" authenticator class, because of the hardcoded dependency > on a specific authn implementation, and working out how to sanely extend > the logic once it's possible for a single node to be using different > authenticators for different client sessions. Solvable but will take some > refactoring and might also generate debate about what the right behaviors > are in that scenario. An example is the RoleManager which currently creates > additional role attributes if the Password Authenticator is in use ... > which, now that you mention it, I wonder if that's already broken for the > MutualTlsWithPasswordFallbackAuthenticator. Hmm. > > Anyway, thanks for the feedback -- Joel. > On 7/3/2025 7:52 AM, Tolbert, Andy wrote: > > > 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. >> > >> > >> > >> > >> >
