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
