[
https://issues.apache.org/jira/browse/KAFKA-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14183089#comment-14183089
]
Gwen Shapira commented on KAFKA-1683:
-------------------------------------
Reviewed Zookeeper SASL code to get better handle on where we are heading.
Since our high-level design is inspired by ZK, I encourage everyone involved to
take a look too.
One thing it clarified for me - SASL does not (necessarily) maintain its own
information on the socket. We need to attach "something extra" that will be
able to retrieve authenticated identity and provide some of the
security-protocol specific implementation.
In ZK, this something is a ServerCnxn instance that gets attached to
SelectionKey (nice trick that I was unaware of) and optionally references a
ZooKeeperSaslServer.
In Ivan's patch for KAFKA-1684, we instead extend SocketChannel with a
protocol-specific wrapper and use this to maintain authentication state.
As far as I can see, both solutions are valid, and both allow us to attach
authentication information to a socket/channel and maintain it there - with the
benefit that it can easily match the socket lifecycle.
I need to have one of these exist for the "no authentication" case for this
patch. I'm going to go with Cnxn instance attached to keys and not the
SocketChannel extension, simply because its less code to merge into KAFKA-1684
later :)
For same reason, the Cnxn will be a clear mock - i.e. will not contain any of
the functionality we actually need from a security-protocol-specific object
except authId getters and setters. If we decide to go with Cnxn objects, the
functionality we actually need (handshakes, wrapping) will get implemented in
followup JIRAs and if we decide to keep the SocketChannels, this will go away
anyway.
> 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)
