[
https://issues.apache.org/jira/browse/HADOOP-13565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15450380#comment-15450380
]
Xiaoyu Yao commented on HADOOP-13565:
-------------------------------------
Also notice the change to use servername from http request to build server SPN
and retrieve credential was introduced as part of HADOOP-10158 to support
multiple SPNs. Not sure if rebuild SPN based on client request is necessary for
multiple SPN support. If yes, we can keep the old behavior if no multiple SPN
is being used by authenticating with the default login SPN specified. This way,
the use case above will continue to work after HADOOP-10158.
cc: the original contributor of HADOOP-10158 [~daryn]/[~kihwal] for additional
feedback on this. Thanks in advance!
> 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
> Reporter: Xiaoyu Yao
> Assignee: Xiaoyu Yao
>
> 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 example....@example.com with
> http://NN.example.com:50070 from somehost.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
> header of Host specified by the browser.
> The root cause is KerberosUtil.getServicePrincipal("HTTP", serverName)}} will
> 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 principle (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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
