[
https://issues.apache.org/jira/browse/KAFKA-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14181569#comment-14181569
]
Jay Kreps commented on KAFKA-1683:
----------------------------------
I had imagined the auth happening in the network layer, though I agree that may
be somewhat mixing concerns and your approach sounds like it could potentially
better. There are a few details to work out, though. In the Kerberos case this
is straight-forward since the request is processed in the API layer anyway. But
how will this work for TLS? I was imagining that TLS would use a separate
acceptor in the network layer that after accepting a connection and completing
the handshake would populate the appropriate session fields. However if the
sessions are maintained in the API layer then somehow we will have to work out
how the result of the authentication gets to the api layer. Another issue is
how we remove sessions when the connection closes. We would need to garbage
collect these as connections were closed, and, perhaps more importantly, we
need to ensure that it isn't possible to trick your way into that hash table.
I.e. if the notion of equality for SelectorKey is comparing the underlying file
descriptor, and file descriptors are reused periodically there could be
problems.
The implementation I was something like this. Currently we attach the current
request to each socket in the socket server. Instead of this we would attach
some object that could hold the session, the current request, and any other
future things we need. For TLS the user information would be populated after
the handshake but before the acceptor hands the connection over to the
processor thread. For Kerberos the session would be populated in
KafkaApis.handleAuthenticate (or whatever we call it). The only advantage to
this approach that I see is that the session lifetime is easily tied to the
connection (which is what we want) and it will be easy to validate this.
I was thinking of the session concept as being a somewhat generic feature of
the network layer to maintain per-connection state so in that sense it isn't
too terrible to have it be part of the network<>api layer contract, though I
agree in general that the simpler we can keep the network stuff the better (it
would be really easy for more and more "business logic" to creep in once we are
doing auth stuff).
> 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)
