zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eugene Koontz (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-938) support Kerberos Authentication
Date Wed, 06 Apr 2011 23:32:05 GMT

    [ 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: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'.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message