hadoop-zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eugene Koontz (JIRA)" <j...@apache.org>
Subject [jira] Updated: (ZOOKEEPER-896) Improve C client to support dynamic authentication schemes
Date Tue, 23 Nov 2010 00:08:13 GMT

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

Eugene Koontz updated ZOOKEEPER-896:
------------------------------------

    Attachment: NIOServerCnxn.patch

Please see NIOServerCnxn.patch, a patch to the  NIOServerCnxn() constructor that authenticates
a client using Kerberos. Contains a lot of hard-wired stuff that needs to be moved to a configuration
file.

> 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: NIOServerCnxn.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.
> 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.


Mime
View raw message