[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Han updated ZOOKEEPER-896:
----------------------------------
    Fix Version/s:     (was: 3.5.3)
                   3.5.4

> Improve 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, java client
>            Reporter: Botond Hejj
>            Assignee: Botond Hejj
>             Fix For: 3.5.4, 3.6.0
>
>         Attachments: NIOServerCnxn.patch, ZOOKEEPER-896.patch, 
> ZOOKEEPER-896.patch, ZOOKEEPER-896.patch, ZOOKEEPER-896.patch, 
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to