[
https://issues.apache.org/jira/browse/ZOOKEEPER-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933063#action_12933063
]
Botond Hejj commented on ZOOKEEPER-896:
---------------------------------------
Short description of the Zookeeper kerberos architecture we made for Mahadev
Konar
I will describe our architecture using the workflow of client authentication
1. Client inits a connection
2. Client adds a kerberos authentication info using the new function I've added
zoo_add_auth_cb(zoohandle, "kerberos", authcallback, authcontext,
completioncallback, data)
where authcallback is a function which is able to get an authentication token
for the connection.
The signature of that callback is the following: typedef struct buffer
(*get_auth_cert_t)(const char *hostname, const void* ctx);
This means it returns the token in the zookeeper buffer structure.
The callback function gets the hostname where the client will actually connect
to and the context which were originally
passed to zoo_add_auth_cb. The context is not used by the c kerberos code but
it might come in handy for other
protocols and it is needed for our planned python binding.
3. At this point the auth_info is just stored at the client side. I've made
modifications in the client to call the registered callback every time before
actually sending the auth_info to the server to ensure the token is not dated.
In this callback basically I use the kerberos gss api to initialize a secure
context (gss_init_sec_context) based on the host of the server where the client
actually connects to. The hostname is required because we do mutual
authentication so only the correct host can decode the token that the client
sends.
4. On the server side we made a kerberos authentication plugin using the
authentication plugin mechanism of the zookeeper server. That authentication
plugin will receive the token and decode the userid of the client from that.
Later the plugin can use this userid to make ACL decisions as well. Basically
it maintains a map of sessions, users.
5. To make really use of this authentication the zookeeper nodes should have
kerberos ACLs. We actually implemented different algorithms to validate an
operation. Basically the plugin have the userid so it can make a decision
purely based on that or use this userid and acl of the node to propogate the
decision to a service or rule engine or anything else.
Let me know if you have further questions
> 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.
