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