[
https://issues.apache.org/jira/browse/KAFKA-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191258#comment-14191258
]
Gwen Shapira commented on KAFKA-1686:
-------------------------------------
Hi [~harsha_ch],
I assume you already started work on this (but no pressure if you didn't. we
are all busy).
I have few questions if you don't mind:
1. How are you adding the additional authentication information to
SocketChannel? I discussed few options in KAFKA-1684, perhaps you can comment
on how your approach compares. If you are inspired by a specific ecosystem
project, perhaps you can share your reference too.
2. It looks like the first step must be to authenticate Kafka broker itself
with Kerberos (otherwise it can't accept client connections at all). This can
be a separate piece that can be committed and tested on its own. Do you think
its worth while splitting this patch? I'm hoping that the smaller stand-alone
components we can get, the easier it will be to get this work committed.
> 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.9.0
> Reporter: Jay Kreps
> Assignee: Sriharsha Chintalapani
> Fix For: 0.9.0
>
>
> 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)
