Re-reading your message I now understand what you are saying. You wish to update the OPTIONS response sent pre SASL. I’m still not sure that’s actually required. The SASL Authenticate/Auth_Response can be what ever you want it to be. As long as what you implement supports recognizing/falling back to the existing method that just does its thing. I think you should be able to add the “list” ability you want for clients that know how to do that.
> On Dec 4, 2024, at 6:41 PM, Jeremiah Jordan <jerem...@datastax.com> wrote: > > 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 | >>>>>>> +---------------------------------------------------------------+ >>>>>>> >>>>>>>
