Hi, I'm happy that this discussion has started because we wanted to propose something we have been working on. I've created https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-31+%28DRAFT%29+Negotiated+authentication+and+authorization with some details. It is a draft and we are open to suggestions and cooperation on that.
Basically what we have been using in DataStax for years already is based on embedding negotiations in SASL messages. In particular, the authentication mechanism chosen by the client is sent in a preamble of the first authentication message. It does not require a new protocol - everything we need is internal to authentication message exchange. It is also backward compatible as if the server does not receive the mechanism preamble, it will just continue assuming the default authentication mechanism. Please have a look and let me know what you think. I'll start a separate thread on that topic soon. thanks - - -- --- ----- -------- ------------- Jacek Lewandowski pt., 26 maj 2023 o 04:08 Dinesh Joshi <djo...@apache.org> napisał(a): > 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 | > +---------------------------------------------------------------+ > > >
