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