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.
>
>
>
>
