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 >
