[
https://issues.apache.org/jira/browse/KAFKA-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14181947#comment-14181947
]
Gwen Shapira commented on KAFKA-1684:
-------------------------------------
Its a large patch, so I didn't do a full review yet. But I wanted to mention
that I love the ChannelFactory implementation. Very nice, clean and reusable.
IMO, this should be a dependency for KAFKA-1686, so we can reuse a lot of the
work done here.
I think it will be cleaner and easier to simply reuse this code and have
SASL/GSSAPI simply work as another channel than trying to cram SASL Kerberos
on the same SocketServer as the existing connections (I've seen this done in
HBase, there is a lot of (isSecure, isWrap, etc) involved).
I'm using this implementation as reference to how Session object can integrate
with a secured nio channel (KAFKA-1683 for reference).
It looks like SSLSocketChannel has a local SSLEngine that I can access to get
the client identity. For consistency, we may want all channels (SASL, TLS,
Kafka) to expose a getIdentity method that SocketServer can use to populate the
Session object.
> 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)
