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 <senth...@microsoft.com.invalid> 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 <rndg...@gmail.com> > 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 > <senth...@microsoft.com.invalid> 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
