Hi Jacek, thanks for sharing! I'm super busy until the middle of next week but I've blocked out some time to read through this. I'm looking forward to the discussion :)
Cheers, Derek On Fri, May 26, 2023 at 2:08 AM Jacek Lewandowski < lewandowski.ja...@gmail.com> wrote: > 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 | >> +---------------------------------------------------------------+ >> >> >> -- +---------------------------------------------------------------+ | 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 | +---------------------------------------------------------------+
