[
https://issues.apache.org/jira/browse/ZOOKEEPER-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016606#comment-13016606
]
Eugene Koontz commented on ZOOKEEPER-938:
-----------------------------------------
Thanks for your review again, Kan. Addressing your points from the beginning
(sorry for the delay):
> 1. Why use SASL? We use SASL in Hadoop because we want to support both
> Kerberos and our own tokens. If we only need to support Kerberos, we might
> have > chosen to use Java GSSAPI directly (which, for example, allows you to
> specify the full Kerberos principal name for the server, whereas in SASL the
> REALM part is picked up from default conf). Do you have a need for
> username/password auth once Kerberos mode is turned on? If your connections
> are
> long-lived, Kerberos-only auth might be enough.
I think the powerful motivation for SASL is its flexibility - for example,
Mahadev is interested in possibly using SSL with Zookeeper. We could use the
SASL EXTERNAL mechanism: http://tools.ietf.org/html/rfc2222#section-7.4 (thanks
to Gary Helmling for pointing this out and the link).
With regard to specifying the full Kerberos principal name for the server, do
you mean that the SASL API does not allow the client to specify the full server
principal name e.g. "zookeeper/my.host.name@MYDOMAIN"?
> 2. If you do need to support username/password in addition to Kerberos, how
> user passwords are stored on server?
> 3. I saw you have a "OpCode.addcred". Is this the operation that allows a
> client to install her chosen password on the server? If so, you need to make
> > sure this operation is done over a Kerberos authenticated and preferably
> encrypted connection. In Hadoop, we only allow delegation tokens to be
> issued to Kerberos authenticated clients.
> 4.
> + } else if (cmd.equals("addcred") && args.length == 3) {
> + String username = args[1];
> + String password = args[2];
> + zk.addCredentials(username,password);
> + }
> It's better not to put passwords on the command line. Either read from a file
> or get it from user interactively.
Thanks for catching this : I've removed all of the "addcred" stuff because of
your good criticism. It was only intended for testing my own DIGEST-MD5
mechanism which should only be used for testing and development, not
production. See two SASL unit tests that use DIGEST-MD5 here:
https://github.com/ekoontz/zookeeper/blob/sasl/src/java/test/org/apache/zookeeper/test/SaslAuthTest.java
https://github.com/ekoontz/zookeeper/blob/sasl/src/java/test/org/apache/zookeeper/test/SaslAuthFailTest.java
However these unit tests do not require the "addcred" command and so I've
removed it.
> 5. You might want to set login configurations programmatically, which is more
> flexible (take a look of what we did in UserGroupInformation.java). I
> think you'll need to support both keytab and TGT cache login.
I find it more flexible to use external text files. Also, if we use the JAAS
configuration format, it's easier to integrate with other services that already
use this format - see this JIRA:
https://issues.apache.org/jira/browse/HADOOP-7070.
> 6. You'll have to deal with relogin issues since your connections are
> long-lived. See UserGroupInformation for some example code. For Hadoop RPC,
> we > don't refresh TGT proactively. The client simply tries to set up a
> connection and if the TGT is expired, the setup will fail. When the client
> detects > the failure, it does relogin and retry connection setup.
This is now addressed with the LoginThread code; see the latest patch. I chose
to do a periodic refresh rather than a fail and retry, since it seemed simpler
to me. I'd be happy to see how a fail and retry replacement would look, though.
> 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
