[
https://issues.apache.org/jira/browse/KAFKA-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14182024#comment-14182024
]
Jay Kreps commented on KAFKA-1683:
----------------------------------
Here is what I was imagining, not sure if this is what you are proposing or
not. It might be worth while to chat quickly to hash it out.
1. We add Session to the request passed from the socket server to the api
layer. Session.authenticatedUser is the user that we will use in the
authorization layer to check permissions. Session.securityCodec is the codec
used to wrap and unwrap messages sent by the socket layer. If the securityCodec
is null, no wrapping or unwrapping is done. We will need an SSL and SASL
implementation of the security codec. The SSL version will wrap the SSLEngine
instance and the SASL version will wrap the SaslServer instance, both of which
provide a wrap and unwrap version.
2. Currently in the socketserver the only state we maintain per connection is
the current request we are reading. This is attached to the channel. We would
replace this with some variable which could hold both the in-progress request
and the session.
3. We would add a new TlsAcceptor that would listen on the TLS port and handle
the handshake for new TLS connections. When the handshake is complete the
TlsAcceptor would grab the user information and populate that field in the
session along with the securityCodec.
4. A similar thing would happen in KafkaApis.handleAuthenticate for Kerberos.
This api would take the next step in the SASL challenge/response cycle and if
it is complete it would populate the authenticatedUser and securityCodec fields
in the session.
5. All authorization checks would be done using Session.authenticatedUser.
6. When the socket server is writing data it will always first run it through
securityCodec.wrap() prior to sending it to make sure it is encrypted. When it
is reading data it will read a complete size delimited message and then do
securityCodec.unwrap() prior to handing that buffer off to the api layer. If
securityCodec is null it will skip this step.
A couple of assumptions here that I'm not sure were explicit:
a. Gwen as you point out the notion of user/subject/principle isn't totally
clear. Can this just be a string we extract rather than a java
Principle/Subject?
b. Is the protocol for encrypted or otherwise integrity checked packets a 4
byte plaintext size followed by an N byte packet? Or is the size also
encrypted? If the later the unwrapping will have to happen in tandem with the
reading which is slightly more complex but perhaps more clean.
> Implement a "session" concept in the socket server
> --------------------------------------------------
>
> Key: KAFKA-1683
> URL: https://issues.apache.org/jira/browse/KAFKA-1683
> Project: Kafka
> Issue Type: Sub-task
> Components: security
> Affects Versions: 0.9.0
> Reporter: Jay Kreps
> Assignee: Gwen Shapira
>
> To implement authentication we need a way to keep track of some things
> between requests. The initial use for this would be remembering the
> authenticated user/principle info, but likely more uses would come up (for
> example we will also need to remember whether and which encryption or
> integrity measures are in place on the socket so we can wrap and unwrap
> writes and reads).
> I was thinking we could just add a Session object that might have a user
> field. The session object would need to get added to RequestChannel.Request
> so it is passed down to the API layer with each request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
