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