You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Eugene Koontz (JIRA)" <ji...@apache.org> on 2011/04/16 00:54:05 UTC
[jira] [Updated] (ZOOKEEPER-938) support Kerberos Authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eugene Koontz updated ZOOKEEPER-938:
------------------------------------
Description:
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 sasl:zkclient@FOOFERS.ORG:cdrwa
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'.
was:
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:zkclient@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'.
> 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 sasl:zkclient@FOOFERS.ORG:cdrwa
> 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