[ https://issues.apache.org/jira/browse/KAFKA-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14734905#comment-14734905 ]
Rajini Sivaram commented on KAFKA-1686: --------------------------------------- The current implementation uses GSSAPI as the only hard-coded SASL mechanism. We are keen to use SASL/PLAIN. Would it be possible to make the SASL mechanism configurable? This task does say "Implement SASL/Kerberos", so if it would be better to open a new task for Sasl/PLAIN, that would be fine too. But it will be good to separate out the Kerberos mechanism related code from the main SASL client/server codepath to make it easier to support multiple mechanisms. We would like to use SSL as the transport layer with SASL/PLAIN for client authentication. I think that would be a straightforward new SecurityProtocol (SSL_SASL) that combines SSLTransportLayer with SaslAuthenticator. Are you planning to add this combination under this task? > Implement SASL/Kerberos > ----------------------- > > Key: KAFKA-1686 > URL: https://issues.apache.org/jira/browse/KAFKA-1686 > Project: Kafka > Issue Type: Sub-task > Components: security > Affects Versions: 0.8.2.1 > Reporter: Jay Kreps > Assignee: Sriharsha Chintalapani > Priority: Blocker > Fix For: 0.8.3 > > > Implement SASL/Kerberos authentication. > To do this we will need to introduce a new SASLRequest and SASLResponse pair > to the client protocol. This request and response will each have only a > single byte[] field and will be used to handle the SASL challenge/response > cycle. Doing this will initialize the SaslServer instance and associate it > with the session in a manner similar to KAFKA-1684. > When using integrity or encryption mechanisms with SASL we will need to wrap > and unwrap bytes as in KAFKA-1684 so the same interface that covers the > SSLEngine will need to also cover the SaslServer instance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)