[
https://issues.apache.org/jira/browse/HADOOP-13565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15638118#comment-15638118
]
Hudson commented on HADOOP-13565:
---------------------------------
SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #10776 (See
[https://builds.apache.org/job/Hadoop-trunk-Commit/10776/])
Revert "HADOOP-13565. KerberosAuthenticationHandler#authenticate should (xyao:
rev 95665a6eea32ff7134ea556db4dd4ae068364fc0)
* (edit)
hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/KerberosAuthenticationHandler.java
> KerberosAuthenticationHandler#authenticate should not rebuild SPN based on
> client request
> -----------------------------------------------------------------------------------------
>
> Key: HADOOP-13565
> URL: https://issues.apache.org/jira/browse/HADOOP-13565
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Affects Versions: 2.5.0
> Reporter: Xiaoyu Yao
> Assignee: Xiaoyu Yao
> Attachments: HADOOP-13565.00.patch
>
>
> In KerberosAuthenticationHandler#authenticate, we use canonicalized server
> name derived from HTTP request to build server SPN and authenticate client.
> This can be problematic if the HTTP client/server are running from a
> non-local Kerberos realm that the local realm has trust with (e.g., NN UI).
> For example,
> The server is running its HTTP endpoint using SPN from the client realm:
> <name>hadoop.http.authentication.kerberos.principal</name>
> <value>HTTP/_HOST/TEST.COM</value>
> When client sends request to namenode at http://NN1.example.com:50070 from
> [email protected].
> The client talks to KDC first and gets a service ticket
> HTTP/NN1.example.com/TEST.COM to authenticate with the server via SPNEGO
> negotiation.
> The authentication will end up with either no valid credential error or
> checksum failure depending on the HTTP client naming resolution or HTTP Host
> field from the request header provided by the browser.
> The root cause is KerberosUtil.getServicePrincipal("HTTP", serverName)}} will
> always return a SPN with local realm (HTTP/[email protected]) no
> matter the server login SPN is from that domain or not.
> The proposed fix is to change to use default server login principal (by
> passing null as the 1st parameter to gssManager.createCredential()) instead.
> This way we avoid dependency on HTTP client behavior (Host header or name
> resolution like CNAME) or assumption on the local realm.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
