[
https://issues.apache.org/jira/browse/KAFKA-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14357665#comment-14357665
]
Sriharsha Chintalapani commented on KAFKA-1684:
-----------------------------------------------
[~junrao] [~jkreps] [~gwenshap] [~jjkoshy]
Hi Everyone,
I am trying to setup a pattern for both ssl and kerberos auth. The above
patch include SSL auth for socket server. Please ignore the changes around
KafkaServer and SockerServer way of creating acceptors as there is work done in
KAFKA-1809.
Based on the comments before I didn't extend any socketChannel instead
SSLChannel more of a wrapper around socketChannel. The SSL handshake done using
non blocking I/O and without any thread.sleeps . Since SocketServer.processor
depends on socketChannels selection I had to use a ConcurrentHashMap which
stores the socketChannel as key and ChannelWrapper as the value. The other
option I've is to extend the SocketChannel or use the SelectionKey attachment
but we are using this attachment for request and response.
The patch also contains a unit test in SocketServerTest which generates
self-signed certs and runs the socket server using those also
sends a request.
I also have GSSChannel for KAFKA-1686 which does the kerberos auth in
similar pattern to SSLChannel. Once this patch gets reviewed, based on the
feedback I'll change the SSL and kerberos patches.
I appreciate any feedback on the above patch.
> 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, 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)
