[ 
https://issues.apache.org/jira/browse/HADOOP-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daryn Sharp updated HADOOP-10158:
---------------------------------

    Attachment: HADOOP-10158.patch

Dynamically use spnego principals in the keytab, including realm discovery for 
the service hosts.  Ideally the existing principal conf key can be removed in a 
future jira.  For now/compatibility, the principal will be immediately logged 
if the key is set.

Introduced a {{SpnegoLoginManager}} that caches the interface's hostname to a 
{{SpnegoLogin}}.  {{SpnegoLogin}} contains a {{LoginContext}} or the exception 
that caused the login failure.  This allows negative caching of failed 
interface hostnames, and returns the same exception to subsequent clients.

It's been tested on our secure clusters.  @Benoy, would you please verify the 
multi-realm support works? I tried to write tests by adding multi-realm support 
to minikdc which mostly worked with a bit of manual hackery.  I then realized 
that a unit test has no hope of working on an offline machine - there's not an 
interface other than localhost for using a second realm.

> 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)

Reply via email to