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
strat
Can also accomplish this on the client instead of server. Make client side
supports multiple authentication mechanisms and does whatever START says.
That's how we have upgraded to different auth mechanisms without downtime
or interruption. For java in example, for AuthProvider of driver override
p
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 bac
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 negoti
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 AUTH
For an example of a delegating authenticator, check out:
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/auth/MutualTlsWithPasswordFallbackAuthenticator.java
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 Shepher
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
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 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
wrote:
> Hi Jacek,
>
> I took a quick look through the CEP an
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
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+
12 matches
Mail list logo
