Hudson commented on HADOOP-13565:

SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #10604 (See 
HADOOP-13565. KerberosAuthenticationHandler#authenticate should not (xyao: rev 
* (edit) 

> 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
>             Fix For: 2.8.0
>         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 
> client.test....@test.com.
> 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/nn.example....@example.com) 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

To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

Reply via email to