[
https://issues.apache.org/jira/browse/KAFKA-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14211612#comment-14211612
]
Gwen Shapira commented on KAFKA-1684:
-------------------------------------
I'm wondering if separate objects for Brokers (ID, host, port) and Channel
(Broker ID, port, channel type) as they are implemented here make sense. Since
now a broker can have multiple ports for multiple channels, this looks
confusing.
I'd like to roll the channel info into Broker, so a broker will now be (ID,
host, port, channel type).
This will allow us to remove the differentiation between "availableBrokers" and
"availableBrokersForChannel" that we have in multiple places.
This means that if we want to support both SSL and Plaintext on the same host,
it will be through two different broker objects.
>From my look through Kafka, it doesn't seem to have terrible side effects and
>can make things clearer, but I hope someone with more experience ([~junrao]?
>[~jkreps]?) can chime in.
> Implement TLS/SSL authentication
> --------------------------------
>
> Key: KAFKA-1684
> URL: https://issues.apache.org/jira/browse/KAFKA-1684
> Project: Kafka
> Issue Type: Sub-task
> Components: security
> Affects Versions: 0.9.0
> Reporter: Jay Kreps
> Assignee: Ivan Lyutov
> Attachments: KAFKA-1684.patch
>
>
> Add an SSL port to the configuration and advertise this as part of the
> metadata request.
> If the SSL port is configured the socket server will need to add a second
> Acceptor thread to listen on it. Connections accepted on this port will need
> to go through the SSL handshake prior to being registered with a Processor
> for request processing.
> SSL requests and responses may need to be wrapped or unwrapped using the
> SSLEngine that was initialized by the acceptor. This wrapping and unwrapping
> is very similar to what will need to be done for SASL-based authentication
> schemes. We should have a uniform interface that covers both of these and we
> will need to store the instance in the session with the request. The socket
> server will have to use this object when reading and writing requests. We
> will need to take care with the FetchRequests as the current
> FileChannel.transferTo mechanism will be incompatible with wrap/unwrap so we
> can only use this optimization for unencrypted sockets that don't require
> userspace translation (wrapping).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
