[
https://issues.apache.org/jira/browse/KAFKA-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14181696#comment-14181696
]
Gwen Shapira commented on KAFKA-1683:
-------------------------------------
Very good points [~jkreps] and [~joestein].
The way I read this - we should not rely on Session to maintain security. This
is too high of a risk and very much re-inventing the wheel. We should use
Session to maintain a generic user information, common to SASL, TLS and
delegation tokens, that the API handlers know how to use. This will basically
serve as the basis for the authorization layer.
The way GSS + JAAS work (and I'm pretty sure we want to use these for Kerberos)
- the client and server do a little authentication dance when the secured
connection is first established, and the client is left with input and output
streams that are secured. Everything sent and received on that socket
afterwards will be encrypted with the server key and include the client session
token. Decrypting the message and validating the client session token doesn't
require communicating with Kerberos, so while there is certain overhead, it
doesn't involve the network.
If we use this token to populate our Session object with every request, we can
be certain that the information is relevant to current connection and is
unexpired (It will be the client responsibility to renew the token with KRB
occasionally, this is per protocol).
This will be easier to do if we use a separate port for Kerberos connections,
they way we do for TLS, otherwise we'll need another way to figure out whether
to perform the little song-and-dance when accepting the connection. But we can
figure out this part later.
Meanwhile, Session object, populated by SocketServer when creating the request,
sent down to API layer. Since I like having the requestKey in the API, I'll add
the new Session object as an addition, not a replacement.
... and that was a very roundabout way to go back to the original request, but
I had to make sure this still makes sense to me :)
> 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)
