Leaving the naming aside (the hardest part of any software), I am generally positive about your idea. A protocol version bump may be avoidable like you suggested. Perhaps a prototype of this idea is in order to help shape the idea? Would you like to take it on?
> On May 21, 2023, at 4:21 AM, Derek Chen-Becker <de...@chen-becker.org> wrote: > > We had a recent discussion in Slack about how to potentially use the OPTIONS > and SUPPORTED messages in the existing CQL protocol to allow the server to > advertise more than one authentication method and allow the client to then > choose which authenticator to use. The primary use case here is to allow > seamless migration to a new authenticator without having to have all parties > involved agree on a single class (and avoid a disruptive change). There's > already a ticket open that was focused on making a change to the binary > protocol (https://issues.apache.org/jira/browse/CASSANDRA-11471) but I think > that we can accomplish this in a backwards compatible way that avoids a > change to the protocol itself. > > What I propose is to allow a server configured for this graceful auth change > to send an additional value in the [string multimap] body of the SUPPORTED > message that indicates which authenticators are supported, in descending > priority order. For example, if I wanted to migrate my server to support both > PlainTextAuthProvider and some new MyAwesomeAuthProvider, I would configure > my client to query options and the server would respond with > > 'AUTHENTICATORS': ['MyAwesomeAuthProvider', 'PlainTextAuthProvider'] > > The client can then choose from its own supported providers and send it as > part of the STARTUP message [string map] body: > > 'AUTHENTICATOR': 'MyAwesomeAuthenticator' > > I'm not good with naming so feel free to propose a different key for either > of these map entries. In any case, the server then validates that the > client-chosen authenticator is actually supported and would then proceed with > the AUTHENTICATE message. In the case where the client sends an > invalid/unsupported authenticator choice, the server can simply respond with > an AUTHENTICATE using the most-preferred configured authenticator. > > I think this is a better approach than changing the binary protocol because > the mechanism already exists for negotiating options and this seems like a > natural use case that avoids having to create an entirely new version of the > protocol. It does not appear to conflict with the existing protocol > definition but I'm not 100% certain. Section 4.1.1 discusses "Possible > options" for the STARTUP message > (https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v4.spec#L296), > but that's an unfortunate use of English that's ambiguous as to whether it > means "The only ones supported" or "Supported but not exclusively". > > I've taken a look at the Java and Python driver source so far and I can't > find anything that would seem to cause a problem by returning a SUPPORTED > multimap entry that the client isn't aware of (in both they would appear to > ignore it), but I'll also admit that this is the first time I've looked at > this part of the client code and I could be missing something. Is anyone > aware of possible problems that would be caused by using this approach? In > particular, if there are clients that strictly validate all entries in the > SUPPORTED map then this could cause a problem. > > Worst case, we may still need a protocol version bump if the enumeration of > STARTUP options is intended to be strict, but at least this would not require > a new message type and would fit into the existing framework for negotiation > between client and server. > > Thoughts, questions, or concerns would be appreciated. > > Cheers, > > Derek > > -- > +---------------------------------------------------------------+ > | Derek Chen-Becker | > | GPG Key available at https://keybase.io/dchenbecker and | > | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | > | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | > +---------------------------------------------------------------+ >
