Principal Propagation

This is a commercial component of Confluent Platform.

Principal propagation takes the principal from authentication mechanism configured for client to the REST Proxy and propagates that same principal when making requests to the Apache Kafka® broker.

Kafka supports the SSL and SASL authentication mechanisms that are based on the client’s configuration. Principal propagation is supported for the supported Kafka security mechanisms by setting up the client appropriately.

For further reference on Kafka Security, please refer to Kafka Security.


SSL propagation is picked by the plugin when the is set to SSL. For SSL propagation to work, it is required to all load all the certificates corresponding to the required principals in a single client KeyStore file. Once this is done, the plugin would pick the appropriate certificate alias based on the logged on principal while making requests to Kafka . Currently, the logged on principal must exactly match the X500 Principal of the certificate. This is straight forward when SSL is used as the authentication mechanism.

For example, if there were two clients integrated to Confluent REST Proxy the setup could be as simple as below

  • Client A authenticates to Confluent REST Proxy using its key store which contains Certificate-A
  • Client B authenticates to Confluent REST Proxy using its key store which contains Certificate-B
  • Confluent REST Proxy’s key store client.ssl.keystore.location is loaded with Certificate-A and Certificate-B. The certificate is then chosen by the plugin based on who the client is.

If the ACLs need to be setup with different principal other than the default X500 on the Kafka broker, you can provide a custom principal builder for Kafka using the broker



SASL propagation is picked by the plugin when the is set to either of SASL_PLAINTEXT or SASL_SSL. Security plugin supports all the sasl.mechanism supported by Kafka clients. Just like a regular Kafka client, the plugin also expects a JAAS config file to be configured through It is required for all the principals to be specified in the JAAS config file under the section KafkaClient.


SSL is the currently supported, which includes the entire distinguished name (DN) of the client certificate. For principal propagation, be sure to include the entire DN of the client certificate when specifying the principal in the KafkaClient portion of the JAAS configuration.

Also note that you can use to map the DN from the client certificate to a name that can be used for principal propagation. For example, a rule like RULE:^CN=(.*?)$/$1/`, would strip off the CN=` portion of the DN.

Refer to SASL Configuration for details about configuring SASL for a Kafka client and broker.

In the JAAS config file all the principals need to be explicitly specified. The plugin supports specifying principals using following supported mechanisms: GSSAPI, PLAIN, SCRAM-SHA-256 and SCRAM-SHA-512. Also, the plugin ignores any configured sasl.mechanism and picks it automatically based on the LoginModule specified for the principal.

KafkaClient { required
  principal="CN=restproxy/localhost@EXAMPLE.COM"; required
  principal="kafka-client-2@EXAMPLE.COM"; required
  password="alice-secret"; required
  password="alice-secret"; required

Below is the mapping of sasl.mechanism for the configured login modules:

Principal’s Login Module SASL Mechanism
For SCRAM-SHA-256 set
as an option in ScramLoginModule

All the mechanisms except SCRAM-SHA-256 would be automatically detected by the plugin and SCRAM-SHA-256 can be explicitly mentioned as an option in the ScramLoginModule.