Hadoop Common
  1. Hadoop Common
  2. HADOOP-10158

SPNEGO should work with multiple interfaces/SPNs.

    Details

    • Type: Bug Bug
    • Status: Patch Available
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 2.2.0
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Target Version/s:

      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.

      1. HADOOP-10158-readkeytab.patch
        5 kB
        Benoy Antony
      2. HADOOP-10158-readkeytab.patch
        6 kB
        Benoy Antony
      3. HADOOP-10158.patch
        7 kB
        Daryn Sharp
      4. HADOOP-10158.patch
        15 kB
        Daryn Sharp
      5. HADOOP-10158_multiplerealms.patch
        6 kB
        Benoy Antony
      6. HADOOP-10158_multiplerealms.patch
        8 kB
        Benoy Antony
      7. HADOOP-10158_multiplerealms.patch
        12 kB
        Benoy Antony

        Issue Links

          Activity

          Hide
          Daryn Sharp added a comment -

          Alejandro Abdelnur, if/after HADOOP-10322 is integrated, there won't be any dynamic login nor negative cache. It'll be a static lookup to find the subject for a given host.

          Show
          Daryn Sharp added a comment - Alejandro Abdelnur , if/after HADOOP-10322 is integrated, there won't be any dynamic login nor negative cache. It'll be a static lookup to find the subject for a given host.
          Hide
          Alejandro Abdelnur added a comment -

          KerberosAuthenticationHandler.java:

          • loginPrincipal(), it seems it is not considering the case of a 'HTTP@REALM' principal and it would assume it is correct.
          • getLoginForHost():
                  SpnegoLogin newLogin = new SpnegoLogin(principal);
                  spnegoLogin = logins.putIfAbsent(host, newLogin);
                  if (spnegoLogin == null) {
                    spnegoLogin = newLogin;
                  }
                  spnegoLogin.login(keytab);
          

          We should add a comment on the spnegoLogin.login(keytab) invocation that in the case of a race condition the second login attempt is a NOP.

          KerberosUtil.java:

          • getRealmForHost(), typo s/retun/return/. Please add an 'IMPORTANT:’ comment here explaining we are tapping into implementation specific methods of the Oracle and IBM JDKs, it may break in other JDKs or in future versions, and it may blow if a SecurityManager is in place.
          Show
          Alejandro Abdelnur added a comment - KerberosAuthenticationHandler.java: loginPrincipal(), it seems it is not considering the case of a 'HTTP@REALM' principal and it would assume it is correct. getLoginForHost(): SpnegoLogin newLogin = new SpnegoLogin(principal); spnegoLogin = logins.putIfAbsent(host, newLogin); if (spnegoLogin == null ) { spnegoLogin = newLogin; } spnegoLogin.login(keytab); We should add a comment on the spnegoLogin.login(keytab) invocation that in the case of a race condition the second login attempt is a NOP. KerberosUtil.java: getRealmForHost(), typo s/retun/return/. Please add an 'IMPORTANT:’ comment here explaining we are tapping into implementation specific methods of the Oracle and IBM JDKs, it may break in other JDKs or in future versions, and it may blow if a SecurityManager is in place.
          Hide
          Benoy Antony added a comment -

          Fixed the javadoc warnings and attached the patch in new jira HADOOP-10322 to avoid confusion with two different patches in one jira. Please review it.

          Show
          Benoy Antony added a comment - Fixed the javadoc warnings and attached the patch in new jira HADOOP-10322 to avoid confusion with two different patches in one jira. Please review it.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12626404/HADOOP-10158-readkeytab.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 1 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          -1 javadoc. The javadoc tool appears to have generated 2 warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-auth.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3514//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3514//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12626404/HADOOP-10158-readkeytab.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. -1 javadoc . The javadoc tool appears to have generated 2 warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-common-project/hadoop-auth. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3514//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3514//console This message is automatically generated.
          Hide
          Benoy Antony added a comment -

          Attaching the partial patch which reads principals from keytab. This one compiles fine.

          Show
          Benoy Antony added a comment - Attaching the partial patch which reads principals from keytab. This one compiles fine.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12626384/HADOOP-10158-readkeytab.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 1 new or modified test files.

          -1 javac. The patch appears to cause the build to fail.

          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3513//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12626384/HADOOP-10158-readkeytab.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. -1 javac . The patch appears to cause the build to fail. Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3513//console This message is automatically generated.
          Hide
          Benoy Antony added a comment -

          Daryn Sharp ,

          I added a utility method in KerberosUtil which reads a keytab file and returns all the principal names in it. Also wrote a unit test.
          If it looks good , I can provide a method which returns principals for a specified short name (eg. HTTP) .

          Show
          Benoy Antony added a comment - Daryn Sharp , I added a utility method in KerberosUtil which reads a keytab file and returns all the principal names in it. Also wrote a unit test. If it looks good , I can provide a method which returns principals for a specified short name (eg. HTTP) .
          Hide
          Daryn Sharp added a comment -

          CNAMEs are rather problematic for spnego because the RFC doesn't specify behavior. Historically service principals are considered/expected to use the canonicalized hostname. The client resolves the host to ip and ip back to host to get the FQDN for the service principal. For example, I believe Firefox and Safari canonicalize while Chrome does not.

          1. I don't think there's a way in java to dynamically discover all the principals in the keytab. I wanted to do that but couldn't find a way to do so. Did you? If yes, I'll happily build a static cache.
          2. I originally used request.getLocalName() but there's a problem. I use negative entries to avoid clients causing the server to repeatedly try to login. A malicious client can flood the server with bogus hostnames via the Host: header which will cause the negative cache entries to grow w/o bound until the server OOMs. Using the interface's hostname prevents this problem.

          If #1 can be solved, a static cache requires no negative entries in which case we can safely use the Host: header.

          Show
          Daryn Sharp added a comment - CNAMEs are rather problematic for spnego because the RFC doesn't specify behavior. Historically service principals are considered/expected to use the canonicalized hostname. The client resolves the host to ip and ip back to host to get the FQDN for the service principal. For example, I believe Firefox and Safari canonicalize while Chrome does not. I don't think there's a way in java to dynamically discover all the principals in the keytab. I wanted to do that but couldn't find a way to do so. Did you? If yes, I'll happily build a static cache. I originally used request.getLocalName() but there's a problem. I use negative entries to avoid clients causing the server to repeatedly try to login. A malicious client can flood the server with bogus hostnames via the Host: header which will cause the negative cache entries to grow w/o bound until the server OOMs. Using the interface's hostname prevents this problem. If #1 can be solved, a static cache requires no negative entries in which case we can safely use the Host: header.
          Hide
          Benoy Antony added a comment -

          Daryn Sharp 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.

          Show
          Benoy Antony added a comment - Daryn Sharp 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.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12625980/HADOOP-10158.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 1 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          -1 findbugs. The patch appears to introduce 1 new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-auth.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3501//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HADOOP-Build/3501//artifact/trunk/patchprocess/newPatchFindbugsWarningshadoop-auth.html
          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3501//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12625980/HADOOP-10158.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. -1 findbugs . The patch appears to introduce 1 new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-common-project/hadoop-auth. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3501//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HADOOP-Build/3501//artifact/trunk/patchprocess/newPatchFindbugsWarningshadoop-auth.html Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3501//console This message is automatically generated.
          Hide
          Daryn Sharp added a comment -

          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.

          Show
          Daryn Sharp added a comment - 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.
          Hide
          Daryn Sharp added a comment -

          I've got a new patch that automatically logs in spnego principals w/o a config key and handles different realms. I was hung up hacking minikdc to support testing multiple realms before other spnego issues sidetracked me. I'll post a patch later today although the multi-realm minikdc changes might not make it in.

          Show
          Daryn Sharp added a comment - I've got a new patch that automatically logs in spnego principals w/o a config key and handles different realms. I was hung up hacking minikdc to support testing multiple realms before other spnego issues sidetracked me. I'll post a patch later today although the multi-realm minikdc changes might not make it in.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12625103/HADOOP-10158_multiplerealms.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 1 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          -1 findbugs. The patch appears to introduce 1 new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed these unit tests in hadoop-common-project/hadoop-auth hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs:

          org.apache.hadoop.security.authentication.server.TestAltKerberosAuthenticationHandler

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3468//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HADOOP-Build/3468//artifact/trunk/patchprocess/newPatchFindbugsWarningshadoop-common.html
          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3468//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12625103/HADOOP-10158_multiplerealms.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. -1 findbugs . The patch appears to introduce 1 new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. -1 core tests . The patch failed these unit tests in hadoop-common-project/hadoop-auth hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs: org.apache.hadoop.security.authentication.server.TestAltKerberosAuthenticationHandler +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3468//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HADOOP-Build/3468//artifact/trunk/patchprocess/newPatchFindbugsWarningshadoop-common.html Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3468//console This message is automatically generated.
          Hide
          Benoy Antony added a comment -

          Attaching a patch with the following changes for consideration:

          1. Add getServerPrincipals method in SecurityUtil which handles multiple principals
          2. Invoked it from NameNodeHttpServer (for webhdfs) and AuthenticationFilterInitializer (for external urls) in addition to HttpServer (for internal urls)

          Show
          Benoy Antony added a comment - Attaching a patch with the following changes for consideration: 1. Add getServerPrincipals method in SecurityUtil which handles multiple principals 2. Invoked it from NameNodeHttpServer (for webhdfs) and AuthenticationFilterInitializer (for external urls) in addition to HttpServer (for internal urls)
          Hide
          Daryn Sharp added a comment -

          I'll look into this further. I've been distracted by other SPNEGO issues as of late.

          Show
          Daryn Sharp added a comment - I'll look into this further. I've been distracted by other SPNEGO issues as of late.
          Hide
          Alejandro Abdelnur added a comment -

          We should mandate HTTP.

          Regarding different realms, then we verify, in the provided principals, there are no 2 principals with same host and different realm, as the only way to determine the realm is indirectly via the host extracted from the request URL.

          Show
          Alejandro Abdelnur added a comment - We should mandate HTTP. Regarding different realms, then we verify, in the provided principals, there are no 2 principals with same host and different realm, as the only way to determine the realm is indirectly via the host extracted from the request URL.
          Hide
          Daryn Sharp added a comment -

          Deprecation is a good idea. We may want to consider just host and maybe realm to satisfy Benoy's use case. The reason being that spnego mandates HTTP/host@realm as the principal, so letting someone specify something other than HTTP is just letting them shoot themselves in the foot - although I've been abusing it for negative testing.

          Going back to the realm, I wonder if there's a way to let java figure out the realm instead of blindly assuming the default realm? We should see if LoginContext given HTTP/host will find the correct keytab entry instead of assuming default realm.

          Additionally, my first idea was to look for principals for all the interfaces to which the web server is bound. If that's possible, no configuration key would be required at all...

          Show
          Daryn Sharp added a comment - Deprecation is a good idea. We may want to consider just host and maybe realm to satisfy Benoy's use case. The reason being that spnego mandates HTTP/host@realm as the principal, so letting someone specify something other than HTTP is just letting them shoot themselves in the foot - although I've been abusing it for negative testing. Going back to the realm, I wonder if there's a way to let java figure out the realm instead of blindly assuming the default realm? We should see if LoginContext given HTTP/host will find the correct keytab entry instead of assuming default realm. Additionally, my first idea was to look for principals for all the interfaces to which the web server is bound. If that's possible, no configuration key would be required at all...
          Hide
          Alejandro Abdelnur added a comment -

          Daryn Sharp, my problem with the current key is that it implies ONE principal as it is singular. How about adding 'principals' and deprecating 'principal' in favor of 'principals'?

          Show
          Alejandro Abdelnur added a comment - Daryn Sharp , my problem with the current key is that it implies ONE principal as it is singular. How about adding 'principals' and deprecating 'principal' in favor of 'principals'?
          Hide
          Daryn Sharp added a comment -

          Alejandro Abdelnur, I'm a bit hesitant to add yet another config key when extending the existing key to support multiple values seems straightforward and compatible. If there were two keys and both are defined, what should we do? Parse them both?

          KerberosUtil.getServicePrincipal is already handling the lowercasing and subbing of null with the hostname.

          I'll look at Benoy's patch too.

          Show
          Daryn Sharp added a comment - Alejandro Abdelnur , I'm a bit hesitant to add yet another config key when extending the existing key to support multiple values seems straightforward and compatible. If there were two keys and both are defined, what should we do? Parse them both? KerberosUtil.getServicePrincipal is already handling the lowercasing and subbing of null with the hostname. I'll look at Benoy's patch too.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12623729/HADOOP-10158_multiplerealms.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          -1 tests included. The patch doesn't appear to include any new or modified tests.
          Please justify why no new tests are needed for this patch.
          Also please list what manual steps were performed to verify this patch.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed these unit tests in hadoop-common-project/hadoop-auth hadoop-common-project/hadoop-common:

          org.apache.hadoop.security.authentication.server.TestAltKerberosAuthenticationHandler

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3445//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3445//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12623729/HADOOP-10158_multiplerealms.patch against trunk revision . +1 @author . The patch does not contain any @author tags. -1 tests included . The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. -1 core tests . The patch failed these unit tests in hadoop-common-project/hadoop-auth hadoop-common-project/hadoop-common: org.apache.hadoop.security.authentication.server.TestAltKerberosAuthenticationHandler +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3445//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3445//console This message is automatically generated.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12623727/HADOOP-10158_multiplerealms.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          -1 tests included. The patch doesn't appear to include any new or modified tests.
          Please justify why no new tests are needed for this patch.
          Also please list what manual steps were performed to verify this patch.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed these unit tests in hadoop-common-project/hadoop-auth:

          org.apache.hadoop.security.authentication.server.TestAltKerberosAuthenticationHandler

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3444//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3444//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12623727/HADOOP-10158_multiplerealms.patch against trunk revision . +1 @author . The patch does not contain any @author tags. -1 tests included . The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. -1 core tests . The patch failed these unit tests in hadoop-common-project/hadoop-auth: org.apache.hadoop.security.authentication.server.TestAltKerberosAuthenticationHandler +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3444//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3444//console This message is automatically generated.
          Hide
          Benoy Antony added a comment -

          Sorry Alejandro Abdelnur, I did not . I am not taking the feature over from Daryn Sharp unless he wants me to.

          Show
          Benoy Antony added a comment - Sorry Alejandro Abdelnur , I did not . I am not taking the feature over from Daryn Sharp unless he wants me to.
          Hide
          Benoy Antony added a comment -

          Here is the difference in the KerberosAuthenticationHandler

          diff KerberosAuthenticationHandler.java.new KerberosAuthenticationHandler.java.prev
          
          <   Map<String,String> server_principalMap = new HashMap<String,String>();
          190,192d188
          <         String[] parts = servicePrincipal.split("[/@]");
          <         LOG.trace("mapping "+ parts[1] + " to " + servicePrincipal);
          <         server_principalMap.put(parts[1], servicePrincipal);
          327c323
          <                 	  server_principalMap.get(serverName),
          ---
          >                       KerberosUtil.getServicePrincipal("HTTP", serverName),
          
          
          Show
          Benoy Antony added a comment - Here is the difference in the KerberosAuthenticationHandler diff KerberosAuthenticationHandler.java.new KerberosAuthenticationHandler.java.prev < Map<String,String> server_principalMap = new HashMap<String,String>(); 190,192d188 < String[] parts = servicePrincipal.split("[/@]"); < LOG.trace("mapping "+ parts[1] + " to " + servicePrincipal); < server_principalMap.put(parts[1], servicePrincipal); 327c323 < server_principalMap.get(serverName), --- > KerberosUtil.getServicePrincipal("HTTP", serverName),
          Hide
          Alejandro Abdelnur added a comment -

          Benoy Antony, I've quickly looked at your updated the patch but I don't see my comments being addressed, right?

          Show
          Alejandro Abdelnur added a comment - Benoy Antony , I've quickly looked at your updated the patch but I don't see my comments being addressed, right?
          Hide
          Benoy Antony added a comment -

          The change
          1. store the principals in map servername->SPN in init
          2. Lookup SPN using servername in the URL

          Show
          Benoy Antony added a comment - The change 1. store the principals in map servername->SPN in init 2. Lookup SPN using servername in the URL
          Hide
          Benoy Antony added a comment -

          I have tested this patch on our test cluster and works for me.
          I had to make a small change since we have an additional SPN in different realm.
          For reference, I am attaching the patch with change I had to make. It will be great if this requirement (principal in a different realm) can be accommodated .

          Show
          Benoy Antony added a comment - I have tested this patch on our test cluster and works for me. I had to make a small change since we have an additional SPN in different realm. For reference, I am attaching the patch with change I had to make. It will be great if this requirement (principal in a different realm) can be accommodated .
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12622229/HADOOP-10158.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          -1 tests included. The patch doesn't appear to include any new or modified tests.
          Please justify why no new tests are needed for this patch.
          Also please list what manual steps were performed to verify this patch.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed these unit tests in hadoop-common-project/hadoop-auth hadoop-common-project/hadoop-common:

          org.apache.hadoop.security.authentication.server.TestAltKerberosAuthenticationHandler
          org.apache.hadoop.metrics2.impl.TestMetricsSystemImpl

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3415//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3415//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12622229/HADOOP-10158.patch against trunk revision . +1 @author . The patch does not contain any @author tags. -1 tests included . The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. -1 core tests . The patch failed these unit tests in hadoop-common-project/hadoop-auth hadoop-common-project/hadoop-common: org.apache.hadoop.security.authentication.server.TestAltKerberosAuthenticationHandler org.apache.hadoop.metrics2.impl.TestMetricsSystemImpl +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3415//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3415//console This message is automatically generated.
          Hide
          Alejandro Abdelnur added a comment -

          Daryn Sharp, looks good, a few things though:

          • how about using a different config property 'principals' when using multiple principals. And leave the current 'principal' for just one.
          • the serverName value should be lowercased before creating the service principal.
          • can the serverName be NULL? if so, what is the behavior then?
          Show
          Alejandro Abdelnur added a comment - Daryn Sharp , looks good, a few things though: how about using a different config property 'principals' when using multiple principals. And leave the current 'principal' for just one. the serverName value should be lowercased before creating the service principal. can the serverName be NULL? if so, what is the behavior then?
          Hide
          Daryn Sharp added a comment -

          This patch allows multiple principals to be specified via the existing conf key. There's effectively no functional change if only 1 principal is supplied.

          The main changes to the auth handler are:

          1. Support logging in as multiple principals
          2. Create the SPNEGO service principal based on the incoming interface

          No tests due to inherent difficulty of writing portable tests that require multi-interface hosts. It has been tested internally on secure grids.

          Show
          Daryn Sharp added a comment - This patch allows multiple principals to be specified via the existing conf key. There's effectively no functional change if only 1 principal is supplied. The main changes to the auth handler are: Support logging in as multiple principals Create the SPNEGO service principal based on the incoming interface No tests due to inherent difficulty of writing portable tests that require multi-interface hosts. It has been tested internally on secure grids.
          Hide
          Kihwal Lee added a comment -

          The main thing is FsckServlet and the token sevlets. I do not care much about others, but was going to do them for the completeness. We are experimenting with a change in kerberos auth handler, which will require no change in HDFS. I think we will move this jira to the common project and update the tile eventually.

          Show
          Kihwal Lee added a comment - The main thing is FsckServlet and the token sevlets. I do not care much about others, but was going to do them for the completeness. We are experimenting with a change in kerberos auth handler, which will require no change in HDFS. I think we will move this jira to the common project and update the tile eventually.
          Hide
          Haohui Mai added a comment -

          HDFS-5570 proposes to remove GetDelegationTokenServlet, RenewDelegationTokenServlet, CancelDelegationTokenServlet, ListPathsServlet, FileDataServlet, FileChecksumServlets, ContentSummaryServlet. Does it make things easier?

          Show
          Haohui Mai added a comment - HDFS-5570 proposes to remove GetDelegationTokenServlet, RenewDelegationTokenServlet, CancelDelegationTokenServlet, ListPathsServlet, FileDataServlet, FileChecksumServlets, ContentSummaryServlet. Does it make things easier?
          Hide
          Kihwal Lee added a comment -

          Daryn Sharp thinks the kerberos auth handler may be modified to automatically pick the right principal and login on-demand if needed. If the principal is not found in the keytab file, it will reject the client. If this works, multi-SPN support will be possible by just adding right entries to the keytab without involving any upper layer changes (e.g. NameNodeHttpServer).

          Show
          Kihwal Lee added a comment - Daryn Sharp thinks the kerberos auth handler may be modified to automatically pick the right principal and login on-demand if needed. If the principal is not found in the keytab file, it will reject the client. If this works, multi-SPN support will be possible by just adding right entries to the keytab without involving any upper layer changes (e.g. NameNodeHttpServer).

            People

            • Assignee:
              Daryn Sharp
              Reporter:
              Kihwal Lee
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:

                Development