[
https://issues.apache.org/jira/browse/ZOOKEEPER-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016621#comment-13016621
]
Eugene Koontz commented on ZOOKEEPER-938:
-----------------------------------------
> Thanks for addressing some of my previous comments in your new patch. Before
> I comment further, I'd like to understand what use cases you plan to
> support. In your documentation, you explained a znode can have any number of
> <scheme:expression,perms> pairs for specifying the authentication scheme,
> principal name, and permissions for that principal. Is this the only way to
> specify permissions? How does it scale to thousands of users for a single
> node? And if I have a user that needs to access a ZooKeeper tree with
> thousands of nodes, do I have to add this user to every node? In addition to
> USER, > do you have a GROUP concept for specifying permissions?
Hi Kan, I simply made the existing permission functionality useable with SASL.
Adding groups and testing scalability are outside of the scope of this bug.
> As you may already know, Hadoop doesn't use authentication specific names (we
> call them long-names) for specifying permissions. Instead, we convert
> long-names to Hadoop internal short-names using configured rules, and use
> short-names for specifying permissions and permission checking. This has the
> benefits of specifying permissions for a user regardless of which
> authentication scheme the user might use to access the system. It makes
> authorization
> policy independent of authentication. It can also map different external
> users to the same internal user.
That sounds interesting but again it is outside the scope of this bug, I think.
> 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
