[
https://issues.apache.org/jira/browse/HADOOP-10895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14247476#comment-14247476
]
Robert Kanter commented on HADOOP-10895:
----------------------------------------
I was helping [~yzhangal] test this out by deploying Oozie with the hadoop-auth
changes in the patch. The idea would be that Oozie uses
{{KerberosAuthenticator}} even in a non-secure cluster, relying on the fallback
behavior. With the patch, that should now fail because the fallback is
disabled by default.
However, when we tried this, we saw that it still was able to connect with the
{{KerberosAuthenticator}} (and also the {{PsuedoAuthenticator}}. We attached a
debugger and discovered that it wasn't even trying to use Kerberos and
succeeding; it actually looks like the {{KerberosAuthenticator}} can be used to
talk to a non-secure cluster, without falling back. See this code here from
{{KerberosAuthenticator}}:
{code:java}
if (conn.getResponseCode() == HttpURLConnection.HTTP_OK) { // <----- A
LOG.debug("JDK performed authentication on our behalf.");
// If the JDK already did the SPNEGO back-and-forth for
// us, just pull out the token.
AuthenticatedURL.extractToken(conn, token);
return;
} else if (isNegotiate()) { // <----- B
LOG.debug("Performing our own SPNEGO sequence.");
doSpnegoSequence(token);
} else { // <----- C
LOG.debug("Using fallback authenticator sequence.");
Authenticator auth = getFallBackAuthenticator();
// Make sure that the fall back authenticator have the same
// ConnectionConfigurator, since the method might be overridden.
// Otherwise the fall back authenticator might not have the information
// to make the connection (e.g., SSL certificates)
auth.setConnectionConfigurator(connConfigurator);
auth.authenticate(url, token);
}
}
{code}
In the case we were expecting it to fail, we get to Line A. Because it’s a
non-secure cluster, we get an HTTP_OK when we talk to the server, even without
Kerberos credentials. Because of that, it goes ahead normally. As the comment
suggests, Line A can also occur sometimes in a normal Kerberos case.
Line B occurs when we’re doing a Kerberos negotiation. And Lince C occurs when
we’re not doing Kerberos; which is what we were expecting to hit in our test
but didn’t.
We can’t remove Line A; IIRC, we’ve tried that in the past and it’s caused
problems. So, I’m not really sure what we should do here. Regardless of
fallback, it looks like the KerberosAuthenticator can talk to a non-secure
cluster, which was the point of this JIRA. Any ideas [~atm] or [~tucu00]?
> HTTP KerberosAuthenticator fallback should have a flag to disable it
> --------------------------------------------------------------------
>
> Key: HADOOP-10895
> URL: https://issues.apache.org/jira/browse/HADOOP-10895
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Affects Versions: 2.4.1
> Reporter: Alejandro Abdelnur
> Assignee: Yongjun Zhang
> Priority: Blocker
> Attachments: HADOOP-10895.001.patch, HADOOP-10895.002.patch,
> HADOOP-10895.003.patch, HADOOP-10895.003v1.patch, HADOOP-10895.003v2.patch,
> HADOOP-10895.003v2improved.patch, HADOOP-10895.004.patch,
> HADOOP-10895.005.patch, HADOOP-10895.006.patch, HADOOP-10895.007.patch,
> HADOOP-10895.008.patch, HADOOP-10895.009.patch
>
>
> Per review feedback in HADOOP-10771, {{KerberosAuthenticator}} and the
> delegation token version coming in with HADOOP-10771 should have a flag to
> disable fallback to pseudo, similarly to the one that was introduced in
> Hadoop RPC client with HADOOP-9698.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
