[
https://issues.apache.org/jira/browse/ZOOKEEPER-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005449#comment-13005449
]
Eugene Koontz commented on ZOOKEEPER-938:
-----------------------------------------
Hi Mahadev, Thanks for your questions. Also I was glad to talk to you and tproa
in #zookeeper about this.
-How zkclient authenticates
The zookeeper client authenticates by setting the property:
java.security.auth.login.config=$FILE
where $FILE is a JAAS (Java Authentication and Authorization Service)
configuration file. Please see my github wiki link (previous comment)for an
example of such a configuration file.
Internally, this property is used by the Zookeeper class to authenticate with
kerberos.
As far as client credential expiry, I believe that client expiry is the big
remaining feature remaining to be done. The client would need to renew the
credential in a separate thread that wakes up once a day (or some time period),
just as the Zookeeper quorum member (the ZK server) must do. As tproa said on
March 1 in #zookeeper, "when you acquire credentials, look into those
credentials and discover how long they are valid. make your thread wake up in
that time minus some fudge factor to renew".
(and as tproa said, it's easy to test expiry by using the "modprinc" tool).
I am working on getting the extra thread support on both client and server
working now. I also need to get a diagram up about how it works - I'm assuming
that the Zookeeper wiki would be a good place?
I'm really looking forward to getting this in 3.4!
-Eugene
> support Kerberos Authentication
> -------------------------------
>
> Key: ZOOKEEPER-938
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-938
> Project: ZooKeeper
> Issue Type: New Feature
> Components: java client, server
> Reporter: Eugene Koontz
> Assignee: Eugene Koontz
> Fix For: 3.4.0
>
> Attachments: NIOServerCnxn.patch, ZOOKEEPER-938.patch,
> ZOOKEEPER-938.patch, jaas.conf, sasl.patch
>
>
> Support Keberos authentication of clients.
> The following usage would let an admin use Kerberos authentication to assign
> ACLs to authenticated clients.
> 1. Admin logs into zookeeper (not necessarily through Kerberos however).
> 2. Admin decides that a new node called '/mynode' should be owned by the user
> 'zkclient' and have full permissions on this.
> 3. Admin does: zk> create /mynode content kerb:zkcli...@foofers.org:x:cdrwa
> (note: for now, the dummy ':x' is a placeholder for the password, and is
> required by the zk command parser. The user's actual password is not stored
> within Zookeeper; simply put 'x' there.)
> 4. User 'zkclient' logins to kerberos using the command line utility 'kinit'.
> 5. User connects to zookeeper server using a Kerberos-enabled version of
> zkClient (ZookeeperMain).
> 6. Behind the scenes, the client and server exchange authentication
> information. User is now authenticated as 'zkclient'.
> 7. User accesses /mynode with permissions 'cdrwa'.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
