[
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.
