[
https://issues.apache.org/jira/browse/KAFKA-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14693676#comment-14693676
]
Eugene Miretsky edited comment on KAFKA-1683 at 8/12/15 3:39 PM:
-----------------------------------------------------------------
My apologies, poorly worded question. Basically was asking where the user
identity in the session will come from - 1-way SSL doesn't authenticate the
client. I think that KAFKA-1686 will solve it - Kerberos support will allow
authenticating as a specific user, and storing the user identity in a session
for later authorization.
was (Author: emiretsk):
My apologies, poorly worded question. I think that KAFKA-1686 solves it -
Kerberos support will allow authenticating as a specific user, and storing the
user identity in a session for later authorization.
> 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
> Fix For: 0.8.3
>
> Attachments: KAFKA-1683.patch, KAFKA-1683.patch
>
>
> 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)
