Ismael Thank you for the response I've walked through changes for KAFKA-3866. I think it shall fix the case I mentioned.
As for server side, I've added a jira wish issue: https://issues.apache.org/jira/browse/KAFKA-4874 I'm working on project with high security restrictions, so I need to find an application layer solution for now. Thanks Pawel On 9 March 2017 at 09:53, Ismael Juma <ism...@juma.me.uk> wrote: > Hi Pawel, > > It is by design that authentication is only performed during connection > establishment in the broker. Kafka relies on long-lived connections, which > means that another mechanism is needed to handle users who have been > removed from the system. A typical approach is to remove all ACLs for that > user, so that all actions are disallowed for connections that are still > live. Authentication will fail for any new connection. Some people would > prefer to have a way to deal with this scenario via authentication alone, > so it may be worth filing a JIRA. > > Regarding the client-side questions, the ticket refreshes are for the case > where a client needs to re-establish a connection. There are a few > improvements in the following JIRA: > > https://issues.apache.org/jira/browse/KAFKA-3866 > > Maybe you can check if it solves the issue you identified? If not, feel > free to add a comment to that JIRA. > > Thanks, > Ismael > > On Thu, Mar 9, 2017 at 7:27 AM, Paweł Tomasik <p.toma...@o2.pl> wrote: > >> Hi >> I've found a security issue in the kafka SASL implementation. >> It seems that ticket refreshments are not necessary to keep >> client-broker connection up. >> >> Test scenario: >> Client sucessfully connects to the broker using SASL_SSL security >> protocol. Kerberos server is provided by Windows Server 2012 and >> Active Directory >> Client principal account is disabled on Active Directory >> When Ticket expires the connection is still up and running. (Although >> client side is no able to refresh it since account is blocked) >> >> The problem root-cause on client side is located here: >> >> org.apache.kafka.common.security.kerberos::KerberosLogin.java Lines >> 239-263 >> In my test scenario: >> - Relogin fails >> - Thread sleeps for hardocded 10 second delay >> - Next relogin attempt is taken but immediately skipped because >> hasSufficientTimeElapsed returns false (default value of >> minTimeBeforeRelogin is set to 60 seconds) >> - Next attempt is scheduled for next minute, but connection is not closed. >> Process repeats >> >> Application logs: >> 2017-03-06 12:06:30,709 INFO >> [org.apache.kafka.common.security.kerberos.KerberosLogin] >> (kafka-kerberos-refresh-thread) Initiating re-login for >> host/domain.com >> 2017-03-06 12:06:40,713 WARN >> [org.apache.kafka.common.security.kerberos.KerberosLogin] >> (kafka-kerberos-refresh-thread) Not attempting to re-login since the >> last re-login was attempted less than 60 seconds before. >> 2017-03-06 12:06:40,714 WARN >> [org.apache.kafka.common.security.kerberos.KerberosLogin] >> (kafka-kerberos-refresh-thread) No TGT found: will try again at Mon >> Mar 06 12:07:40 CET 2017 >> 2017-03-06 12:06:40,714 INFO >> [org.apache.kafka.common.security.kerberos.KerberosLogin] >> (kafka-kerberos-refresh-thread) TGT refresh sleeping until: Mon Mar 06 >> 12:07:40 CET 2017 >> >> 2017-03-06 12:07:40,714 INFO >> [org.apache.kafka.common.security.kerberos.KerberosLogin] >> (kafka-kerberos-refresh-thread) Initiating logout for host/domain.com >> 2017-03-06 12:07:40,715 INFO >> [org.apache.kafka.common.security.kerberos.KerberosLogin] >> (kafka-kerberos-refresh-thread) Initiating re-login for >> host/domain.com >> 2017-03-06 12:07:50,717 WARN >> [org.apache.kafka.common.security.kerberos.KerberosLogin] >> (kafka-kerberos-refresh-thread) Not attempting to re-login since the >> last re-login was attempted less than 60 seconds before. >> 2017-03-06 12:07:50,717 WARN >> [org.apache.kafka.common.security.kerberos.KerberosLogin] >> (kafka-kerberos-refresh-thread) No TGT found: will try again at Mon >> Mar 06 12:08:50 CET 2017 >> >> On the broker side the problem seems to be even more severe, as the it >> seems not to verify ticket expiration date. >> So once client provides a valid ticket, it is no longer challenged >> against its refreshments. >> It looks that authentication is performed only once at connection >> establish point by default Krb5LoginModule implementation. It is not >> challenged later. >> >> I'm new here, so forgive me if it is not a good place for such posts. >> >> >> Best regards >> Pawel >> -- Paweł Tomasik
