Versions Compared

Old Version 1

changes.mady.by.user Jason Gustafson

Saved on

compared with

New Version 2

changes.mady.by.user Jason Gustafson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Kafka exposes a PrincipalBuilder interface which can be used to derive custom principals in the context of SSL client authentication. Its current interface is this:

 

Code Block
interface PrincipalBuilder extends Configurable {
  void configure(Map<String, ?> configs);
   
  Principal buildPrincipal(TransportLayer transportLayer, Authenticator authenticator) throws KafkaException;
  
  void close() throws KafkaException;
}

 

At the moment, the Principal derived from the PrincipalBuilder is converted to a KafkaPrincipal before being passed to the Authorizer. The KafkaPrincipal object is distinguished primarily by the fact that it has a principal type, which is always set to "User" when converting from a Principal. The Authorizer implementation depends on KafkaPrincipal indirectly through the following objects:

 

Code Block
case class Session(principal: KafkaPrincipal, clientAddress: InetAddress)
 
case class Acl(principal: KafkaPrincipal, permissionType: PermissionType, host: String, operation: Operation)

 

In this KIP, we aim to solve two primary problems with this interfacethe current PrincipalBuilder interface:

  1. The PrincipalBuilder is currently only used for SSL authentication. We want to extend it to SASL mechanisms in general including GSSAPI. This includes unifying the Kerberos name translation rules.
  2. Due to the conversion from Principal to KafkaPrincipal, a custom Authorizer implementation cannot leverage any enrichment provided at the authentication layer in a convenient way. For example, if the authorizer had a notion of groups, it might be reasonable to derive a group id from the client certificate OU field. In that case, the principal builder would have to pack that group id into the principal name to pass it through to the Authorizer. This might be reasonable for just one additional field, but it would be more general and much more convenient to pass through the enriched Principal all the way to Authorizer. (Note this is the problem which was trying to be solved in KIP-111.)

Additionally, the interface has a couple shortcomings from an API perspective that we want to address:

  1. There is no use case that we are aware of which requires access to the Authenticator directly. The closest use case would be the SASL authenticator, but what we actually need is the SaslServer. Furthermore, there is an odd circular dependence between the PrincipalBuilder and the Authenticator: Authenticator exposes a principal() method which uses the PrincipalBuilder by passing itself as the second parameter.
  2. There is no use case that we are aware of which requires the TransportLayer itself. What client SSL authentication actually needs is access to the SSLSession which is provided by the JRE. Hence we are unnecessarily exposing Kafka internals.

...