...
Discussion thread: here
JIRA:
Jira | ||||||
---|---|---|---|---|---|---|
|
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
...
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 the current PrincipalBuilder
interface:
- 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. - Due to the conversion from
Principal
toKafkaPrincipal,
a customAuthorizer
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 theAuthorizer
. This might be reasonable for just one additional field, but it would be more general and much more convenient to pass through the enrichedPrincipal
all the way toAuthorizer
. (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:
- 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 theSaslServer
. Furthermore, there is an odd circular dependence between thePrincipalBuilder
and theAuthenticator
:Authenticator
exposes aprincipal()
method which uses thePrincipalBuilder
by passing itself as the second parameter. - There is no use case that we are aware of which requires the
TransportLayer
itself. What client SSL authentication actually needs is access to theSSLSession
which is provided by the JRE. Hence we are unnecessarily exposing Kafka internals.
...