Versions Compared

Key

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

...

This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current stateUnder Discussion

...

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Kafka currently supports providing a JAAS LoginModule for pluggable authentication when using SASL and SASL_SSL.  When using the SASL_SSL channel, the channel will override the setting for requiring a client certificate to be presented so it is not possible to require client authentication by providing a certificate.  This makes sense for SASL_SSL as the SASL mechanism will be used for authentication instead of a client certificate in this case.  However, this means that the SSL channel needs to be used when a client certificate is required for authentication.  Currently when using SSL the only authentication that is done is the SSL handshake between client and server.  It would also be ideal to be able to provide an option for custom authentication for the SSL channel that uses the client's X509 credentials that goes beyond the SSL handshake.  This would allow providing extra authentication based on a user's requirements.

Public Interfaces

Configuration changes

An optional JAAS LoginModule for the SSL channel can be configured using the namespace SslKafkaServer.  The implementation will be provided by the end user on the classpath.  For example:

...

-Djava.security.auth.login.config will still be used to specify the location of the configuration file.

API change

An abstract X509LoginModule class can be provided to make it easier for a user to custom build a LoginModule.

...

Code Block
languagejava
public class TestSslLoginModule implements LoginModule {
    @Override
    public void initialize(Subject subject, CallbackHandler callbackHandler, Map<String, ?> sharedState,
            Map<String, ?> options) {
        Callback[] callbacks = new Callback[1];
        X509Callback callback = new X509Callback();
        callbacks[0] = callback;
        try {
            callbackHandler.handle(callbacks);
        } catch (Exception e) {
            //handle exception
        }
		//acquire X509 credentials
        Certificate[] certs = callback.getPeerCertificates();
        X509Certificate x509 = (X509Certificate) certs[0];

    }
 
    @Override
    public boolean login() throws LoginException {
        //do custom login logic
        return true;
    }
    //Rest of methods below
}

 

Proposed Changes

New JaasContext.Type called SSL_SERVER and new Global Context name called SslKafkaServer.  A user will be able to provide a custom JAAS module under the name of SslKafkaServer.  This is in addition to the existing ways to configure a SASL server with KafkaServer.  By using SslKafkaServer a separate LoginModule configuration can be provided for both SSL and SASL/SASL_SSL.

...

The principal will be extracted from the Subject provided by the JAAS LoginModule.  If the LoginModule does not set a principal in the Subject then the SslServerAuthenticator will use the configured PrincipalBuilder object to build the Principal. 

Compatibility, Deprecation, and Migration Plan

There will be no impact on existing users if they do not configure a JAAS module for the SSL channel.  This is an optional configuration and everything should continue to work as it did before.  The PrincipalBuilder class will still be used to build the principal if there is no configured JAAS module.  If a JAAS module is configured then the SslServerAuthenticator will first try and use a principal set on the Subject from the JAAS module but will fallback to the PrincipalBuilder class if one is not set which should preserve backwards compatibility.

Test Plan

There will be unit tests written based off of SslTransportLayerTest for the new configuration and the existing tests that will run for both unit and system tests will show that nothing has been broken for existing users.

Rejected Alternatives

Custom Authenticator

A change could be made to allow a user to configure a custom Authenticator but this would not be a standard API and would be a Kafka only API implementation.  It is better to allow the configuration of a JAAS LoginModule as that is an existing standard and is more flexible.

...