[
https://issues.apache.org/jira/browse/ZOOKEEPER-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Botond Hejj updated ZOOKEEPER-896:
----------------------------------
Description:
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.
was:
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.
> 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.3, 3.6.0
>
> Attachments: NIOServerCnxn.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.4#6332)
