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 | > > >> +---------------------------------------------------------------+ > > >> > > >> > >
