[
https://issues.apache.org/jira/browse/ZOOKEEPER-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007296#comment-13007296
]
Kan Zhang commented on ZOOKEEPER-938:
-------------------------------------
@Eugene,
Congrats on getting Kerberos to work! Mahadev asked me to take a look of your
patch. We did a similar thing for Hadoop you might want to take a look. You
don't have a design doc attached, at the risk of misunderstanding you, here are
my initial comments.
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.
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. {code}
+ } else if (cmd.equals("addcred") && args.length == 3) {
+ String username = args[1];
+ String password = args[2];
+ zk.addCredentials(username,password);
+ }
{code}
It's better not to put passwords on the command line. Either read from a file
or get it from user interactively.
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.
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.
> 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:[email protected]: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
