[
https://issues.apache.org/jira/browse/KAFKA-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14181323#comment-14181323
]
Joe Stein commented on KAFKA-1683:
----------------------------------
[~gwenshap] We need to be careful with auth once only constant session.
Revoking credentials would not be picked up until a new session was created.
So we need some balance between always re-auth and session for scale. All of
this down to deploy requirements many/most should be ok I think with the
re-auth only once every X timeframe or always (levers/knobs). Or some other
part of the code/system that is constantly checking auth changes and notifying
the server of that change expiring the session then (making it async in nature).
I really like it to be in the KafkaApi that is where all the good stuff is and
this should mixed in cleanly with that IMHO.
> 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)
