hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiaoyu Yao (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-13565) KerberosAuthenticationHandler#authenticate should not rebuild SPN based on client request
Date Tue, 13 Dec 2016 23:05:58 GMT

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

Xiaoyu Yao commented on HADOOP-13565:
-------------------------------------

Thanks [~daryn]. The problem is in HADOOP-13565, we enforce an additional principal check
requiring SPNEGO principal to have three complete parts: HTTP, hostname and realm. This prevents
principal like HTTP/localhost from being used. 

By relaxing the requirement on realm parts, we maintain the support for principals like HTTP/host.
Unlike the first two patches for HADOOP-13890, the 3rd one is a simpler fix that addresses
the compatibility concerns without changing the original unit tests. To make this work, we
also found and fixed the KerberosName parsing bug to handle principals like HTTP/host. Please
review and let me know your thoughts.

> 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, 3.0.0-alpha2
>
>         Attachments: HADOOP-13565.00.patch, HADOOP-13565.01.patch, HADOOP-13565.02.patch,
HADOOP-13565.03.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.com@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.com@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
(v6.3.4#6332)

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


Mime
View raw message