> On Sep 22, 2021, at 8:03 AM, Bowen Song <bo...@bso.ng> wrote: > > Interesting. The better approach is to match the certificate's common name or > SAN to the CQL username. This way the authorisation part, which depends on > the CQL username, will continue to work as usual. > Yes, that is one way of deriving an identity. The other "standard" mechanism is to use spiffe ids[1] to encode an identity and to derive your username/principal from it.
Dinesh [1] https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md#2-spiffe-id > On 22/09/2021 15:40, Dinesh Joshi wrote: >>> On Sep 22, 2021, at 2:02 AM, Bowen Song <bo...@bso.ng >>> <mailto:bo...@bso.ng>> wrote: >>> Out of curiosity, I have two further questions. >>> >>> 1. I know the client can optionally provider a certificate for the TLS >>> handshake, but is it possible to require the client to provide a >>> certificate? >>> >> >> Yep, you can turn on require_client_auth under the client_encyrption_options >> in Cassandra YAML to >> https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L1160 >> <https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L1160> >> This requires the CQL client to provide client certificates. >> >>> 2. Does Cassandra check that the username matches the client certificate? >>> E.g. TLS client certificate is issued to "bob", but logging in CQL using >>> the username "charol". >>> >> no. The client certificates that you provide should be trusted by the >> server's truststore for the connection to succeed. Thats it. AFAIK there >> isn't an accepted secure standard to encode a "username" inside a TLS client >> certificate that we can use to derive a principal. >>> If the answer to Q2 is "no", it would mean that the TLS client certificate >>> is used for primary authentication (but not authorisation), and the CQL >>> username & password will be used for secondary authentication and >>> authorisation. Anyone who has a valid client certificate and private key >>> pair can impersonate any CQL user if they know the username and password. >>> Depending on the threat model, this may or may not pose a security risk. >>> >> The client certificate can be used to ensure that it is a trusted client. If >> a bad actor is able to not only obtain a valid client certificate but also >> the private key pair then you have bigger issues :) >> >> In 4.0 the IAuthenticator interface has changed slightly to pass down the >> client certificates that the server receives. In theory one can create an >> implementation of this interface that can derive an identity from the client >> certificates and then use that to perform authentication. This would give >> you what you're looking for. If you'd like, you can go as far as ignoring >> the username/password passed down from the cilent and only rely on the >> identity encoded in the certificate as your source of truth. >> >> Dinesh >>> >>> On 21/09/2021 23:16, Dinesh Joshi wrote: >>>> It sort of supports it. You still need to send in the username/password >>>> credentials along with the client certificate to authenticate. Cassandra >>>> will not derive the identity purely from the client certificate. >>>> >>>> Dinesh >>>> >>>>> On Sep 21, 2021, at 11:59 AM, S G <sg.online.em...@gmail.com> >>>>> <mailto:sg.online.em...@gmail.com> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Does anyone know if opensource Cassandra support mutual-TLS ? >>>>> The documentation doesn't conclusively deny or accept the support for the >>>>> same. >>>>> >>>>> Thanks ! >>
