[ 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:40 PM: ----------------------------------------------------------------- My apologies, poorly worded question. Basically was asking where the user/client identity in the session will come from - 1-way SSL (KAFKA-1690) 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. 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. > 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)