Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Thu, 30 Jan 2014 17:38:13 +0000 (UTC)
From: "Benoy Antony (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12682724.1386176397814.11431.1391103493297@arcas>
In-Reply-To: <JIRA.12682724.1386176397814@arcas>
References: <JIRA.12682724.1386176397814@arcas>
Subject: [jira] [Commented] (HADOOP-10158) SPNEGO should work with multiple
 interfaces/SPNs.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Benoy Antony commented on HADOOP-10158:
---------------------------------------

[~daryn] I have reviewed the patch. Thanks for the effort put in to satisfy our requirements.

This will not work for us since the patch canonicalizes the hostname with the call _request.getLocalName()_. This restricts the server principals that can be used to the canonicalized one.  If I have CNAME to HOSTNAME and want to authenticate with  both {HTTP/CNAME, HTTP/HOSTNAME} then that will not work. _request.getLocalName()_  will always return HOSTNAME. 

An alternate implementation can be like this:

1. During init, login all the principals specified in principal conf key . If no principals are specified, read all principals matching HTTP/*@* from keytab and login all of them and cache them with a servername-Realm map
This avoids any synchronization , caching and Realm determination.  This is an optional improvement. If needed, I can provide an implementation for this. 

2. In authenticate, look up a principal with _request.getServerName() _ in addition to  _request.getLocalName()_  .  This is required for us to work. This removes the canonicalization issue. 

> SPNEGO should work with multiple interfaces/SPNs.
> -------------------------------------------------
>
>                 Key: HADOOP-10158
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10158
>             Project: Hadoop Common
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Kihwal Lee
>            Assignee: Daryn Sharp
>            Priority: Critical
>         Attachments: HADOOP-10158.patch, HADOOP-10158.patch, HADOOP-10158_multiplerealms.patch, HADOOP-10158_multiplerealms.patch, HADOOP-10158_multiplerealms.patch
>
>
> This is the list of internal servlets added by namenode.
> | Name | Auth | Need to be accessible by end users |
> | StartupProgressServlet | none | no |
> | GetDelegationTokenServlet | internal SPNEGO | yes |
> | RenewDelegationTokenServlet | internal SPNEGO | yes |
> |  CancelDelegationTokenServlet | internal SPNEGO | yes |
> |  FsckServlet | internal SPNEGO | yes |
> |  GetImageServlet | internal SPNEGO | no |
> |  ListPathsServlet | token in query | yes |
> |  FileDataServlet | token in query | yes |
> |  FileChecksumServlets | token in query | yes |
> | ContentSummaryServlet | token in query | yes |
> GetDelegationTokenServlet, RenewDelegationTokenServlet, CancelDelegationTokenServlet and FsckServlet are accessed by end users, but hard-coded to use the internal SPNEGO filter.
> If a name node HTTP server binds to multiple external IP addresses, the internal SPNEGO service principal name may not work with an address to which end users are connecting.  The current SPNEGO implementation in Hadoop is limited to use a single service principal per filter.
> If the underlying hadoop kerberos authentication handler cannot easily be modified, we can at least create a separate auth filter for the end-user facing servlets so that their service principals can be independently configured. If not defined, it should fall back to the current behavior.


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)