hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kan Zhang (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-6419) Change RPC layer to support SASL based mutual authentication
Date Mon, 01 Feb 2010 22:14:18 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828300#action_12828300
] 

Kan Zhang commented on HADOOP-6419:
-----------------------------------

Hi Philip,  I uploaded a new patch that incorporates your comments. Specifically,

bq. you could put the constant inside the AuthMethod enum

Done.

bq. It's pretty unintuitive that you had to pass the two parts of the server's kerberos identity
as the protocol and server parameters here.  How did you figure that out?

Same as you did, from the source code. If we use Java GSSAPI directly, it allows
you to specify the full Kerberos principal name as a single parameter, which makes
sense. However, Java Sasl splits it into 2 parts and the second hostname part can't 
be null (if I remember corerctly).

bq. Am I right in guessing that the reason we don't use the "plain" mechanism for SASL is
that we wish to avoid SASL's extra framing?

Yes.

bq. Are there likely to be different types of TokenSelectors?

Yes, we currently have Delegation Token (for authenticating to NN) and Job Token 
(for Task to authenticate to TaskTracker). We may have more types of tokens in the
future. A token is just a shared secret key known to the two authenticating parties. How
to generate and distribute the keys may be different for different protocols, but the way
the keys are used by the authentication layer is the same, which is what has been 
abstracted out to the RPC layer.

bq. I think you're going for some type safety by using generics there, but I'm missing what
it's buying you.

It doesn't buy you much (mainly for the benefit of developers who read the source code) 
as the type information are erased by the compiler.

bq. At this point, token's not a token, but merely data, no? You might rename that variable,
to avoid confusion.

Done.

bq. The code here would be clearer if you extracted this into a "void wrapWithSasl(response)"
method.

Done.

bq. I think they must have meant com.sun.jndi.ldap.sasl.SaslInputStream, which seems to be
part of OpenJDK and GPL'd, so never us mind.

Yes, and we don't want to be dependent on com.sun packages.

bq. Could this just be @TokenRpcAuth(enum) and @KerberosRpcAuth(SERVER_PRINCIPLE_KEY)?

TokenInfo has been changed to single element annotation. However, we can't
use enum. We need to specify the type of TokenSelector used, as there may be 
more than one type. KeberosInfo's only element has been changed to "value", 
so that one can use the short form you suggested above.

bq. Turns out it will fall back to Kerberos if the token's not present.

The reason for this is that on some protocols, both Kerberos and token-based 
authentication will be supported. And when a client has both credentials available,
we favor token over Kerberos since it's cheaper to use tokens.

bq. I take it that this is a main() test and not a @Test test because Kerberos doesn't exist
on Hudson?

Yes, we don't have Kerberos infrastructure (KDC and keys, etc) on Hudson. 
This test is currently ran manually with a local Kerberos setup.

bq. SaslInputStream/SaslOutputStream

They are tested by TestSaslRPC.

Thank you for your comments. Let me know if you have any further comments.

> Change RPC layer to support SASL based mutual authentication
> ------------------------------------------------------------
>
>                 Key: HADOOP-6419
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6419
>             Project: Hadoop Common
>          Issue Type: New Feature
>          Components: security
>            Reporter: Kan Zhang
>            Assignee: Kan Zhang
>         Attachments: c6419-26.patch, c6419-39.patch, c6419-45.patch, c6419-66.patch,
c6419-67.patch, c6419-69.patch, c6419-70.patch, c6419-72.patch
>
>
> The authentication mechanism to use will be SASL DIGEST-MD5 (see RFC-2222 and RFC-2831)
or SASL GSSAPI/Kerberos. Since J2SE 5, Sun provides a SASL implementation by default. Both
our delegation token and job token can be used as credentials for SASL DIGEST-MD5 authentication.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message