Botond Hejj commented on ZOOKEEPER-896:


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.

Reply via email to