Conversation from Twitter:
Jeremy Whitlock @ whitlockjc:
Does anyone have time to talk about @ apachekafka custom SASL mechanism? It seems like only @ confluentinc employees worked on it lately (based on “git blame”) and the ones I’ve reached out to don’t have time. 
Sarwar Bhuiyan @sarwarbhuiyan:
Hey, are you subscribed to the user or dev mailing lists? Best place is to ask in one of those based on whether you want to use one or develop one. Probably after that you might have to create a KIP and discuss on the dev list. Hope this helps.
Jeremy Whitlock:
Ah, the mailing list. I can join that, but a KIP likely isn’t required as this work will not make it back to Kafka. I just need to better understand the SASL stuff as Kafka uses it and makes it pluggable.
Sarwar Bhuiyan:
However, a much more practical example might be the OAUTHBEARER example
Jeremy Whitlock:
My only gripe with that use case is it’s a more complex use case, making it hard to tell what’s mechanism specific versus SASL specific. I’ll figure it out, thanks a lot.
Sarwar Bhuiyan :
No worries. Hope to see your question on the dev list
Jeremy Whitlock :
It’s there, although I’m making sense of things more. I think the SASL/PLAIN implementation is slightly harder to understand due to no SaslClient implementation, but the SASL OAUTHBEARER has a good deal of extra stuff in it making it harder too. Rolling on the floor laughing
Sarwar Bhuiyan :
Oh ok. Maybe the plain one is better? We wrote an extension to that using the login handler but that’s proprietary
Jeremy Whitlock :
I just am missing a simple explanation of the moving parts, how data gets from one to the next, and where they run (client, server, …). I feel like I get it and then I start asking more questions, like why callbacks are necessary.
Sarwar Bhuiyan :
I think it’s like a backend and a front end type thing. The callback handler allows you to extend the backend login lookup/validation
Jeremy Whitlock:
So if you don’t want to allow extension, as in your SASL mechanism is specific, you could likely avoid callbacks?
Sarwar Bhuiyan:
Yes
The default sasl plain one looks for a configured handler but without it all the user/pass combos are read from the jaas configuration property
Jeremy Whitlock:
The last bit that isn’t clear is the purpose of the LoginModule, it’s suppose to authenticate the user but if it’s on the client, it must consult the server to authenticate. It appears the SaslClient is responsible for this, but I don’t fully know how it’s wired.
Sarwar Bhuiyan @sarwarbhuiyan:
The login module side is the front end api which accepts the security credentials from the Kafka side
Jeremy Whitlock:
Kafka side, as in from user to Kafka or from Kafka client to server? PlainLoginModule doesn’t do anything other than add credentials to Subject. The PlainServerCallbackHandler does the real work, and how it gets from LoginModule to server is unknown. For OAUTH, I can kinda see
Jeremy Whitlock:
Not seeing a PlainSaslClient, I’m just not 100% sure of how the data is sent to the PlainSaslServer. Inspecting SASL/OAUTHBEARER I think I see how the client gets the data and sends it to the server, but with the extra bits going on, hard to tell for sure.
Jeremy Whitlock:
Also, I appreciate your time. Feel free to respond on the mailing list is this isn’t ideal.