[ https://issues.apache.org/jira/browse/KAFKA-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Francois Fernando updated KAFKA-10099: -------------------------------------- Description: Following authentication code in kafka still puzzles me (Lines 67-74: [https://github.com/apache/kafka/blob/3cdc78e6bb1f83973a14ce1550fe3874f7348b05/clients/src/main/java/org/apache/kafka/common/security/authenticator/SaslServerCallbackHandler.java]). {{private void handleAuthorizeCallback(AuthorizeCallback ac) {}} {{ String authenticationID = ac.getAuthenticationID();}} {{ String authorizationID = ac.getAuthorizationID();}} {{ LOG.info("Successfully authenticated client: authenticationID={}; authorizationID={}.",}} \{{ authenticationID, authorizationID);}} {{ ac.setAuthorized(true);}} {{ ac.setAuthorizedID(authenticationID);}} {{}}} In a kafka cluster secured with Kerberos, using a kafka keytab with principal like `sys_read/reader.myorg.c...@myorg.corp` results in: authenticationID = sys_r...@myorg.corp; authorizationID = sys_read/reader.myorg.c...@myorg.corp Last line of above method sets the authorizedID to authenticationID not authorizationID. From my understanding of java security, the principal will become what's set in AuthorizedID. This means the ACL definitions can't use the full principal string as the principal as authorizer will never see it. This leads to a confusing bug in spark structured streaming where the ACL has to be added without the host part of the principal. was: Following authentication code in kafka still puzzles me (Lines 67-74: https://github.com/apache/kafka/blob/3cdc78e6bb1f83973a14ce1550fe3874f7348b05/clients/src/main/java/org/apache/kafka/common/security/authenticator/SaslServerCallbackHandler.java). {{private void handleAuthorizeCallback(AuthorizeCallback ac) {}} {{ String authenticationID = ac.getAuthenticationID();}} {{ String authorizationID = ac.getAuthorizationID();}} {{ LOG.info("Successfully authenticated client: authenticationID={}; authorizationID={}.",}} {{ authenticationID, authorizationID);}} {{ ac.setAuthorized(true);}} {{ ac.setAuthorizedID(authenticationID);}} {{}}} In a kafka cluster secured with Kerberos, using a kafka keytab with principal like `sys_read/reader.myorg.c...@myorg.corp` results in: authenticationID = sys_r...@myorg.corp; authorizationID = sys_read/reader.myorg.c...@myorg.corp Last line of above method sets the authorizedID to authenticationID not authorizationID. From my understanding of java security, the principal will become what's set in AuthorizedID. This means the ACL definitions can't use the full principal string as the principal as authorizer will never see it. > Kerberos authentication sets java authrizedId to authenticationId not > autherizationId > ------------------------------------------------------------------------------------- > > Key: KAFKA-10099 > URL: https://issues.apache.org/jira/browse/KAFKA-10099 > Project: Kafka > Issue Type: Bug > Components: security > Affects Versions: 2.3.0 > Reporter: Francois Fernando > Priority: Major > > Following authentication code in kafka still puzzles me (Lines 67-74: > [https://github.com/apache/kafka/blob/3cdc78e6bb1f83973a14ce1550fe3874f7348b05/clients/src/main/java/org/apache/kafka/common/security/authenticator/SaslServerCallbackHandler.java]). > {{private void handleAuthorizeCallback(AuthorizeCallback ac) {}} > {{ String authenticationID = ac.getAuthenticationID();}} > {{ String authorizationID = ac.getAuthorizationID();}} > {{ LOG.info("Successfully authenticated client: authenticationID={}; > authorizationID={}.",}} > \{{ authenticationID, authorizationID);}} > {{ ac.setAuthorized(true);}} > {{ ac.setAuthorizedID(authenticationID);}} > {{}}} > In a kafka cluster secured with Kerberos, using a kafka keytab with principal > like `sys_read/reader.myorg.c...@myorg.corp` results in: > authenticationID = sys_r...@myorg.corp; > authorizationID = sys_read/reader.myorg.c...@myorg.corp > Last line of above method sets the authorizedID to authenticationID not > authorizationID. From my understanding of java security, the principal will > become what's set in AuthorizedID. > This means the ACL definitions can't use the full principal string as the > principal as authorizer will never see it. This leads to a confusing bug in > spark structured streaming where the ACL has to be added without the host > part of the principal. -- This message was sent by Atlassian Jira (v8.3.4#803005)