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