[
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)
