...

It is worth noting that these extensions would lack a digital signature and therefore should not be used for critical use-cases where security is a concern.

Public Interfaces

`SaslExtensions` class - encapsulates extensions and parses them to/from strings

public class SaslExtensions {
    public SaslExtensions()

    public SaslExtensions(String extensions)

    public SaslExtensions(Map<String, String> extensionMap)

    public String extensionValue(String name)

    public Set<String> extensionNames()

    @Override
    public String toString()
}

`SaslExtensionsCallback` - generic callback to hold extensions

...

A user would make use of the changes in this KIP in the following way:

1. Create a custom ClientCallbackHandler and configure the client to use itLoginCallbackHandler

   1. This handler should handle the `SaslExtensionsCallback` in his `handle()` method and attach custom extensions to the Subject

      Code Block
      TODO
      Code Block
      @Override public void handle(Callback[] callbacks) { for (Callback callback : callbacks) { if (callback instanceof OAuthBearerTokenCallback) handleTokenCallback((OAuthBearerTokenCallback) callback); else if (callback instanceof SaslExtensionsCallback) { Map<String, String> extensions = new HashMap<>(); extensions.put("trace-id", "123"); ((SaslExtensionsCallback) callback).extensions(extensions); } else throw new UnsupportedCallbackException(callback); } }

      
      

2. A custom principal builder can then make use of the new extension

   1. 
      

      Code Block

      public class CustomPrincipalBuilder implements KafkaPrincipalBuilder { @Override public KafkaPrincipal build(AuthenticationContext context) { if (context instanceof SaslAuthenticationContext) { SaslServer saslServer = ((SaslAuthenticationContext) context).server(); String traceId = saslServer.getNegotiatedPropery("trace-id"); return new CustomPrincipal("", saslServer, traceId); } throw new Exception(); } }

      
      

...

• What impact (if any) will there be on existing users? NoneIf we are changing behavior how will we phase out the older behavior? We are simply adding better extendability options
• Mark `ScramExtensionsCallback` as deprecated and remove it in next major release (3.0)

Rejected Alternatives

• Add customizable extensions to every SASL client
  • | Not easily implementable, as we depend on a third-party library for PLAIN authentication
  • It is possible we implement configurable extensions for SCRAM as well. We would need to simply remove the checks in `ScramSaslServer` and then any custom callback handler could populate the extensions

...