I think you are talking about the SASL handshake? The authenticator can override the SASL handler for the connections. The negotiating authenticator just needs to implement that override? You can then implement the flow you mentioned.
At DataStax we do basically exactly that to support negotiated authentication. As you suggest the “default” mechanism is also specified in the config for the negotiating authenticator such that you can have it fall back to the “current” mechanism for existing clients that don’t try to negotiate. Which means it can be seamlessly enabled. -Jeremiah > On Dec 4, 2024, at 5:27 PM, Joel Shepherd <sheph...@amazon.com> wrote: > > A negotiating authenticator is appealing, but I'm concerned that it doesn't > have a good migration story. If a client has not been configured with a > "negotiating provider" before it attempts to connect to a node with a > negotiating authenticator, the results will be unpredictable. Today, the > AUTHENTICATE message names the node-selected authenticator for the client, > but there is no requirement that the client validate that it can work with > the authenticator before its own auth provider/authenticator generates its > initial AUTH_RESPONSE. From what I can tell, most don't validate. There is > not a way today at the protocol level for the client to tell the node "I > can't work with the authenticator you've specified: let's try a different > one." The node can't communicate that to the client either. Once a node > switches over to a negotiating authenticator, many clients will assume that > they can authenticate using the same mechanism that they always have. This > would require the node's authenticator to heuristically determine how the > client is trying to authenticate in order to continue the handshake. That > seems unreliable, but I believe without that then switching nodes to a > negotiating authenticator will either require downtime (to switch the clients > as well) or result in client authentication failures. > > If the negotiation is done up-front via the OPTIONS, SUPPORTED and START > messages, I believe it can be done in a way that enables clients and/or nodes > to authenticate as they do today if needed. For example, clients that do not > initiate connections with an OPTIONS message and that do not select an auth > method via their START message can be assumed to not support negotiation, and > the node can use today's existing authentication mechanism with the client. > Similarly, nodes that do not specify available authenticators through their > SUPPORTED response can be assumed to not support negotiation and the client > can use today's authentication mechanism without negotiation. > > Given that, I don't believe introducing a new negotiating authenticator is > the best path forward. > > If it would help, I can provide documentation on the proposed protocol-based > mechanism: it may be unclear here. > > Thanks -- Joel. > >> On 12/3/2024 5:34 PM, J. D. Jordan wrote: >> I think you can implement this as a single authenticator that has separate >> configuration of the supported mechanisms. So the single authenticator >> maintained is the “negotiating authenticator” which can proxy off to which >> ever other mechanisms you want. >> >>>> On Dec 3, 2024, at 6:37 PM, Joel Shepherd <sheph...@amazon.com> wrote: >>> >>> I'm interested, at least in a more narrowly-scoped subset of CEP-31: >>> authentication negotiation only, configured via YAML (not dynamically), >>> with CQL integration, proxy authorization, multiple role managers and new >>> authn mechanisms out of scope. >>> >>> I've started working through Derek's proposal in >>> https://issues.apache.org/jira/browse/CASSANDRA-11471 , to use the >>> OPTIONS/SUPPORTED exchange to start the negotiation, and continue it by >>> extending STARTUP to optionally include the client's preferred >>> authentication mechanism. I believe this can be done in a way that is >>> compatible (i.e., maintains the status quo) for clients and/or nodes that >>> aren't negotiation-aware. Having such a mechanism in place would make it >>> much safer to roll out new authenticators, which is something else I'm >>> interested in. >>> >>> This is looking like a more invasive change on the Cassandra core side, >>> however. If I'm reading things correctly, the DatabaseDescriptor maintains >>> a single authenticator across all clients. Negotiation would be much more >>> useful if different clients could use different node-supported >>> authentication mechanisms: e.g., automated clients could use mTLS and apps >>> for humans could use Kerberos, both against a single node. This means that >>> authenticator needs to be pushed down to connection- or session-level, >>> which will affect everything from the daemon startup code to the >>> authentication workflow. That's not a reason not to do it, but it is a >>> little invasive. Maybe I'm overlooking a better way. >>> >>> If time allows, I'll put together a rough patch this month for initial >>> feedback, but am happy to discuss here or however folks want to proceed. >>> >>> -- Joel. >>> >>> >>> On 2024/09/19 17:56:07 Dinesh Joshi wrote: >>>> This is an area of interest for me personally and is an important feature. >>>> Not sure if the original author is going to see it through since we've not >>>> had any discussion on it for a while. >>>> >>>> Is anybody interested in picking this up? >>>> >>>> Dinesh >>>> >>>> On Thu, Sep 19, 2024 at 10:54 AM Patrick McFadin <pm...@gmail.com> wrote: >>>> >>>>> Hi Jacek, >>>>> >>>>> I was doing some housekeeping on CEPs and noticed this stalled. Is this >>>>> still a CEP you are advocating for? >>>>> >>>>> Anyone else that knows the status, feel free to add in. >>>>> >>>>> Patrick >>>>> >>>>> On Wed, May 31, 2023 at 8:26 AM Derek Chen-Becker <de...@chen-becker.org> >>>>> wrote: >>>>> >>>>>> Hi Jacek, >>>>>> >>>>>> I took a quick look through the CEP and I think I understand the >>>>>> implementation you're donating. I don't think that the approach you're >>>>>> taking and the approach I proposed are contradictory, but I want to make >>>>>> sure I'm understanding some aspects of the CEP: >>>>>> >>>>>> 1. Is there any mechanism for discovery so that the client knows which >>>>>> authenticators are supported? The main use case I see here is that since >>>>>> the client drives selection of the authenticator, the client probably >>>>>> wants >>>>>> to utilize the strongest mutually supported mechanism >>>>>> 2. Can you specify the client/server exchange in a state diagram or more >>>>>> clearly detail which messages are involved? The CEP states that "The >>>>>> driver >>>>>> sends an additional preamble along with the initial SASL authentication >>>>>> message". Is the "initial SASL auth message" the AUTH_RESPONSE? Are you >>>>>> basically saying that the server sends the AUTHENTICATE message with a >>>>>> class name, so does the client basically respond with "No, here's the >>>>>> authenticator I want to use" in the preamble? >>>>>> 3. Does the donated code for the server already handle hot >>>>>> reconfiguration of authenticators? The CEP states "We want to make it >>>>>> possible to add, ..." so I wasn't sure if that was future work or not >>>>>> >>>>>> I think I need to re-read and digest, but on first run-through this looks >>>>>> really interesting! >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Derek >>>>>> >>>>>> On Fri, May 26, 2023 at 8:09 AM Jacek Lewandowski < >>>>>> lewandowski.ja...@gmail.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to start a discussion on negotiated authentication and >>>>>>> improvements to authentication, authorization, and role management in >>>>>>> general. A draft of proposed changes is included in CEP-31. >>>>>>> >>>>>>> >>>>>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-31+%28DRAFT%29+Negotiated+authentication+and+authorization >>>>>>> >>>>>>> thanks, >>>>>>> - - -- --- ----- -------- ------------- >>>>>>> Jacek Lewandowski >>>>>>> >>>>>> >>>>>> -- >>>>>> +---------------------------------------------------------------+ >>>>>> | 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 | >>>>>> +---------------------------------------------------------------+ >>>>>> >>>>>>
