[ https://issues.apache.org/jira/browse/ZOOKEEPER-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933066#action_12933066 ]
Botond Hejj commented on ZOOKEEPER-896: --------------------------------------- Eugene: We patched also the java code but we used a more hacky faster approach so if you could write a clean patch that would be useful for us as well. In that approach the user is not able to register a callback but the user can remove the authentication info and readd it if a new connection made. This approach required less change in the zookeeper code but there might be a chance if the authentication packet stays in the queue for long and token expires fast than the authentication fails. > Improve C client to support dynamic authentication schemes > ---------------------------------------------------------- > > Key: ZOOKEEPER-896 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-896 > Project: Zookeeper > Issue Type: Improvement > Components: c client > Affects Versions: 3.3.1 > Reporter: Botond Hejj > Assignee: Botond Hejj > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-896.patch > > > When we started exploring zookeeper for our requirements we found the > authentication mechanism is not flexible enough. > We want to use kerberos for authentication but using the current API we ran > into a few problems. The idea is that we get a kerberos token on the client > side and than send that token to the server with a kerberos scheme. A server > side authentication plugin can use that token to authenticate the client and > also use the token for authorization. > We ran into two problems with this approach: > 1. A different kerberos token is needed for each different server that client > can connect to since kerberos uses mutual authentication. That means when the > client acquires this kerberos token it has to know which server it connects > to and generate the token according to that. The client currently can't > generate a token for a specific server. The token stored in the auth_info is > used for all the servers. > 2. The kerberos token might have an expiry time so if the client loses the > connection to the server and than it tries to reconnect it should acquire a > new token. That is not possible currently since the token is stored in > auth_info and reused for every connection. > The problem can be solved if we allow the client to register a callback for > authentication instead a static token. This can be a callback with an > argument which passes the current host string. The zookeeper client code > could call this callback before it sends the authentication info to the > server to get a fresh server specific token. > This would solve our problem with the kerberos authentication and also could > be used for other more dynamic authentication schemes. > The solution could be generalization also for the java client as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.