[HADOOP-10158] SPNEGO should work with multiple interfaces/SPNs.

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 2.2.0
• Fix Version/s: 2.5.0
• Target Version/s: 2.5.0
• Hadoop Flags: Reviewed
• Assignee: Daryn Sharp
• Reporter: Kihwal Lee
• Created: 04/Dec/13 16:59
• Updated: 06/Nov/16 06:28
• Resolved: 08/May/14 18:28

Description

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.

Issue Links

• is depended upon by: OOZIE-1865 Oozie servers can't talk to each other with Oozie HA and Kerberos
• is related to: HADOOP-10307 Support multiple Authentication mechanisms for HTTP
• relates to: HADOOP-10702 KerberosAuthenticationHandler does not log the principal names correctly
• requires: HADOOP-10322 Add ability to read principal names from a keytab