[
https://issues.apache.org/jira/browse/KAFKA-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14180983#comment-14180983
]
Gwen Shapira commented on KAFKA-1683:
-------------------------------------
We need to map SelectorKeys (representing connections) to a Session object
(containing user and other identifiers).
This can be done in a map that will get populated when an AUTH request appears
and used by the rest of the APIs.
Since the Request that appears in the API contains the SelectorKeys (RequestKey
field, currently unused, but I'm glad someone had the foresight to add it), I
think it makes much more sense to manage this mapping in KafkaApis, rather than
in SocketServer. This can be internal to the API layer - create the Session
object and add the mapping (Request.requestKey.hashcode()->Session) when an
AuthRequest happens and have the various handlers use it to map the requests
with the keys to sessions.
An alternative design would be to maintain this mapping in the SocketServer and
have the processor add this information to Request when it creates the request.
I don't like the idea of moving this responsibility to the network layer when
it can be done on a higher level, which it can - because the request object
already has a session identifier.
So unless someone objects - I'm going with the modification to KafkaApis.
[~jkreps][~joestein] - any issues with this?
As a side note, other systems (pretty much anything HTTP-based, REST, Thrift,
etc) send the Kerberos session ticket in every request and use it to
re-authenticate and provide the identity rather than maintain a stable session.
This can be an alternative design, although I'd think its one with higher
overhead.
> 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)
