A conflict / overlap was brought to my attention so wanted to bring it here.
CEP 31 has the following Goals: "Proxy authorization which let a role execute commands on behalf of the other role” Proposed Changes: "A proxy authorization is a mechanism where role A can grant a special permission to other role B, so that B after successful authentication is authorized as A and has all A permissions. We implement a new permission for this purpose.” This sounds in-sync with CEP 64; https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/440305049/CEP-64+Proxy+Execution+Support If anyone is working on CEP 31 can address the overlap that would be great. I don’t see a lot of details in 31 so I can’t say for sure if 64 covers it or not. > On Dec 5, 2024, at 10:38 AM, Joel Shepherd <[email protected]> wrote: > > Thanks Jeremiah and Chris - Feedback heard. Let me reconsider doing this > directly through the existing provider/authenticator model, with minimal > changes to the native protocol. I'd be happy if that simplified things. > > Also, if I'm overly focused on enabling an interruption-free migration > strategy (from the current authn handshake to a negotiated handshake), let me > know. It seems desirable to me, but it also adds complexity. > > Thanks -- Joel. > > On 12/4/2024 5:09 PM, J. D. Jordan wrote: >> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>>>> 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 >>>>>>>> <[email protected]> >>>>>>>> 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 < >>>>>>>>> [email protected]> 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 | >>>>>>>>> +---------------------------------------------------------------+ >>>>>>>>> >>>>>>>>>
