Hi Senthil. Yes, you should read KIP-368: Allow SASL Connections to
Periodically Re-Authenticate
(https://cwiki.apache.org/confluence/display/KAFKA/KIP-368%3A+Allow+SASL+Connections+to+Periodically+Re-Authenticate).
This KIP was added in AK 2.2 and addresses your question about
re-authentication.
Ron
On Wed, Jan 22, 2020 at 10:31 AM Senthilnathan Muthusamy
wrote:
>
> Hi Ron,
>
> Thanks for the details and this answers my question (i.e. we can have 2
> listeners - 1 with SASL_SSL and another with SSL to achieve this).
>
> Another question related to oAuth token revoke scenario. Say once broker
> authenticated the presented oAuth token and if is valid for 24 hours.
>1. Will broker automatically invalid the token after expiry?
>2. Also if the oAuth server revoked the token (say in the 6th hour), is
> there a way on the broker side to invalid the token thru any configuration
> (something like revalidating the token in a configured internal to make sure
> the token still valid)?
>
> Regards,
> Senthil
>
> -Original Message-
> From: Ron Dagostino
> Sent: Wednesday, January 22, 2020 5:15 AM
> To: dev@kafka.apache.org
> Subject: [EXTERNAL] Re: Enable both SASL & SSL authentication...
>
> <<< some of our clients uses oAuth and some uses cert based auth Hi Senthil.
> Brokers support different clients using different types of authentication, so
> there is no problem here. The way it works is via the broker's listener --
> each one listens on a separate port and is either a SSL listener (mutual cert
> authentication), a SASL listener (or which there are two styles, with and
> without encryption -- more on that below), or a PLAINTEXT listener (no
> authentication). One thing to clarify is that any particular client cannot
> authenticate with multiple identities -- Kafka does not support multiple
> identities on a single session -- so if the client connects on the port
> associated with SASL then the broker will ignore any client-side certificate.
> As mentioned, there are two types of listeners associated with SASL: one
> called SASL_PLAINTEXT where the communication happens in the clear and
> another called SASL_SSL where the communication is TLS-encrypted. It is this
> second case -- SASL_SSL -- where the client could potentially present a
> certificate, but the broker ignores it in this case even if the broker's
> config says it is required. This is done because of the constraint mentioned
> above -- a particular client can authenticate with at most 1 identity over
> any single connection.
>
> I hope this helps. You may find the blog post at
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.confluent.io%2Fblog%2Fkafka-listeners-explained&data=02%7C01%7Csenthilm%40microsoft.com%7C0896e8bba4554c0ca32c08d79f3d1a8e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637152957096095910&sdata=WE2SeBn2c%2BAce2YgAwfjvCvsYdZS8r8sSNZewZFFEUA%3D&reserved=0
> to be interesting and helpful, too.
>
> Ron
>
> On Wed, Jan 22, 2020 at 2:07 AM Senthilnathan Muthusamy
> wrote:
> >
> > Hi,
> >
> > We want both SASL (oAuthBearer) & SSL authentication to be enabled. However
> > based on the below doc, the SSL auth will be disabled if SASL is enabled.
> >
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .confluent.io%2Fcurrent%2Fkafka%2Fauthentication_ssl.html%23brokers&am
> > p;data=02%7C01%7Csenthilm%40microsoft.com%7C0896e8bba4554c0ca32c08d79f
> > 3d1a8e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637152957096105864
> > &sdata=4uECZuJXY19JNS4GbzYSGeeDqMPIXE%2FTtMnSdsILX8U%3D&reserv
> > ed=0
> >
> >
> > If any SASL authentication mechanisms are enabled for a given listener,
> > then SSL client authentication is disabled-even if you have specified
> > ssl.client.auth=required and the broker authenticates clients only using
> > SASL on that listener.
> >
> > How can we have both SASL & SSL authentication enabled as some of our
> > clients uses oAuth and some uses cert based auth?
> >
> > Appreciate any pointers.
> >
> > Thanks,
> > Senthil