Uploaded image for project: 'Hadoop Common'
  1. Hadoop Common
  2. HADOOP-11717

Add Redirecting WebSSO behavior with JWT Token in Hadoop Auth

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.8.0, 3.0.0-alpha1
    • Component/s: security
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      Extend AltKerberosAuthenticationHandler to provide WebSSO flow for UIs.

      The actual authentication is done by some external service that the handler will redirect to when there is no hadoop.auth cookie and no JWT token found in the incoming request.

      Using JWT provides a number of benefits:

      • It is not tied to any specific authentication mechanism - so buys us many SSO integrations
      • It is cryptographically verifiable for determining whether it can be trusted
      • Checking for expiration allows for a limited lifetime and window for compromised use

      This will introduce the use of nimbus-jose-jwt library for processing, validating and parsing JWT tokens.

      1. HADOOP-11717-1.patch
        29 kB
        Larry McCay
      2. HADOOP-11717-2.patch
        35 kB
        Larry McCay
      3. HADOOP-11717-3.patch
        38 kB
        Larry McCay
      4. HADOOP-11717-4.patch
        38 kB
        Larry McCay
      5. HADOOP-11717-5.patch
        38 kB
        Larry McCay
      6. HADOOP-11717-6.patch
        41 kB
        Larry McCay
      7. HADOOP-11717-7.patch
        40 kB
        Larry McCay
      8. HADOOP-11717-8.patch
        40 kB
        Larry McCay
      9. RedirectingWebSSOwithJWTforHadoopWebUIs.pdf
        234 kB
        Larry McCay

        Issue Links

          Activity

          Hide
          lmccay Larry McCay added a comment -

          Initial patch attached.

          Show
          lmccay Larry McCay added a comment - Initial patch attached.
          Hide
          hadoopqa Hadoop QA added a comment -

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

          +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. There were no new javadoc warning messages.

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

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

          -1 release audit. The applied patch generated 1 release audit warnings.

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

          Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/5941//testReport/
          Release audit warnings: https://builds.apache.org/job/PreCommit-HADOOP-Build/5941//artifact/patchprocess/patchReleaseAuditProblems.txt
          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/5941//console

          This message is automatically generated.

          Show
          hadoopqa Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12704603/HADOOP-11717-1.patch against trunk revision bd0a9ba. +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 . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 2.0.3) warnings. -1 release audit . The applied patch generated 1 release audit warnings. +1 core tests . The patch passed unit tests in hadoop-common-project/hadoop-auth. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/5941//testReport/ Release audit warnings: https://builds.apache.org/job/PreCommit-HADOOP-Build/5941//artifact/patchprocess/patchReleaseAuditProblems.txt Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/5941//console This message is automatically generated.
          Hide
          lmccay Larry McCay added a comment -

          Missing apache header will provide new patch

          Show
          lmccay Larry McCay added a comment - Missing apache header will provide new patch
          Hide
          lmccay Larry McCay added a comment -

          New patch with appropriate header in the test file.

          Show
          lmccay Larry McCay added a comment - New patch with appropriate header in the test file.
          Hide
          hadoopqa Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12704613/HADOOP-11717-2.patch
          against trunk revision bd0a9ba.

          +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. There were no new javadoc warning messages.

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

          +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) 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.

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

          This message is automatically generated.

          Show
          hadoopqa Hadoop QA added a comment - +1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12704613/HADOOP-11717-2.patch against trunk revision bd0a9ba. +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 . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 2.0.3) 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. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/5943//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/5943//console This message is automatically generated.
          Hide
          drankye Kai Zheng added a comment -

          Hi Larry McCay,

          I'm glad to see this, thanks for taking this ! As mentioned in HADOOP-10959, I had a prototype implementing a Kerberos based token (JWT token) authentication approach, covering both terminal command use case and web UI case. I attempted to break down the work but looks like it doesn't go smoothly, as you can see in HADOOP-10670 and HADOOP-10671. I built the similar web SSO flow for Hadoop web UI starting with a JWT token. So with that experience, I will look at your patch and see if anything I can help with.

          One thing to clarify is, in the Hadoop auth handler you enhanced, if a JWT token is there in the session after redirected back, you will validate the token in the handler itself, right ? No delegate to another service to authenticate the token, right ? If so, I'm wondering if you could leave the chance in your codes, so that other effort like HADOOP-10959 can pluggin or customize the token validation mechanism or behavior. Thanks.

          By the way a minor, nimbus-jose-jwt library is a good choice, as also made in Apache Kerby, where the TokenPreauth is being implemented for the Kerberos library and KDC. I thought we're much aligned in this part.

          Show
          drankye Kai Zheng added a comment - Hi Larry McCay , I'm glad to see this, thanks for taking this ! As mentioned in HADOOP-10959 , I had a prototype implementing a Kerberos based token (JWT token) authentication approach, covering both terminal command use case and web UI case. I attempted to break down the work but looks like it doesn't go smoothly, as you can see in HADOOP-10670 and HADOOP-10671 . I built the similar web SSO flow for Hadoop web UI starting with a JWT token. So with that experience, I will look at your patch and see if anything I can help with. One thing to clarify is, in the Hadoop auth handler you enhanced, if a JWT token is there in the session after redirected back, you will validate the token in the handler itself, right ? No delegate to another service to authenticate the token, right ? If so, I'm wondering if you could leave the chance in your codes, so that other effort like HADOOP-10959 can pluggin or customize the token validation mechanism or behavior. Thanks. By the way a minor, nimbus-jose-jwt library is a good choice, as also made in Apache Kerby, where the TokenPreauth is being implemented for the Kerberos library and KDC. I thought we're much aligned in this part.
          Hide
          lmccay Larry McCay added a comment -

          Hello Kai Zheng - Good to hear from you. I think that there is certainly room for making a pluggable validation mechanism. I'd rather not slow down progress by trying to do too much here though. Let's do as little as we can here to get the job done. If subclassing the proposed class and overriding a particular validation method will suffice then I think that should be the short term goal. I'm not sure that we need a specific classname configuration item for a token validator but I could be convinced otherwise. The JWT validation rules are pretty clear and we are covering the main ones in this patch.

          • signature verification
          • expiration date validation
          • audience validation

          There isn't anything for scopes yet - if you have particular needs there then we should add it.

          I suggest that we get something simple in for now and evolve it as needed.

          I am happy to see that we are aligned on nimbus - the API is simple and succinct and works as expected. I have been really pleased with it.

          Show
          lmccay Larry McCay added a comment - Hello Kai Zheng - Good to hear from you. I think that there is certainly room for making a pluggable validation mechanism. I'd rather not slow down progress by trying to do too much here though. Let's do as little as we can here to get the job done. If subclassing the proposed class and overriding a particular validation method will suffice then I think that should be the short term goal. I'm not sure that we need a specific classname configuration item for a token validator but I could be convinced otherwise. The JWT validation rules are pretty clear and we are covering the main ones in this patch. signature verification expiration date validation audience validation There isn't anything for scopes yet - if you have particular needs there then we should add it. I suggest that we get something simple in for now and evolve it as needed. I am happy to see that we are aligned on nimbus - the API is simple and succinct and works as expected. I have been really pleased with it.
          Hide
          drankye Kai Zheng added a comment -

          I read the non-trivial patch, it's really decent and of very good quality. A good job !
          My comments are so far:
          1. Why we need to add BC and nimbus library deps to hadoop-project, since they're already in hadoop-auth project ?
          2. For secure protecting JWT token, we should use SSL for the web flow. We might need to add such security consideration texts in the new handler header comment.
          3. I'm not sure we could avoid using cookie to pass the JWT token, since it's not a good practice. By post and putting it in the body instead ?
          4. Anyway, please limit cookie just as one method to convey token, so better to avoid cookie stuffs in the many places (variables, words in logs and etc.).
          5. I guess in somewhere we need document how to configure the new authentication handler, to feed the new properties like the login url.
          6. Do we support the new mechanism for the both web UI and web hdfs ? Allow SSO between the two ? How would you go ? In HADOOP-10671, it allows the same configurations set for the both, thus SSO effect can be achieved.
          7. Do we consider JWT token lifetime ? I thought maybe we should limit the lifetime of the resultant authentication token (hadoop-auth) to the lifetime of the JWT token.
          8. Where originalUrl is used ? A constant for it ?
          9. Can you construct loginURL only when necessary ? I thought it makes sense.
          10. I thought handleJWTToken instead of handleJWTCookie. Anyway, for it:
          1) Why we have a userName parameter ? Looks like not used.
          2) Would we rewrite it for better reading and extension. Suggest:

          handleJWTCookie(jwtToken) {
            boolean validated = validateToken(jwtToken);
            ...
          }
          
          validateToken(jwtToken) {
            validateSignature(jwtToken);
            validateAudiences(jwtToken);
            validateExpiration(jwtToken);
          }
          

          Other effort like HADOOP-10959 can easily override validateToken method.
          3) I thought the coding style here might be a little different from the project.
          11. Only userName is used as the result of web sso, but I'm not sure that's enough to ensure its uniqueness.
          12. Ref. below, the message isn't correct. By the way, looks like we only support PEM format.

          +      if (pem.startsWith(PEM_HEADER)) {
          +        message = "CertificateException - do not include PEM header and footer";
          +      }
          
          Show
          drankye Kai Zheng added a comment - I read the non-trivial patch, it's really decent and of very good quality. A good job ! My comments are so far: 1. Why we need to add BC and nimbus library deps to hadoop-project, since they're already in hadoop-auth project ? 2. For secure protecting JWT token, we should use SSL for the web flow. We might need to add such security consideration texts in the new handler header comment. 3. I'm not sure we could avoid using cookie to pass the JWT token, since it's not a good practice. By post and putting it in the body instead ? 4. Anyway, please limit cookie just as one method to convey token, so better to avoid cookie stuffs in the many places (variables, words in logs and etc.). 5. I guess in somewhere we need document how to configure the new authentication handler, to feed the new properties like the login url. 6. Do we support the new mechanism for the both web UI and web hdfs ? Allow SSO between the two ? How would you go ? In HADOOP-10671 , it allows the same configurations set for the both, thus SSO effect can be achieved. 7. Do we consider JWT token lifetime ? I thought maybe we should limit the lifetime of the resultant authentication token (hadoop-auth) to the lifetime of the JWT token. 8. Where originalUrl is used ? A constant for it ? 9. Can you construct loginURL only when necessary ? I thought it makes sense. 10. I thought handleJWTToken instead of handleJWTCookie . Anyway, for it: 1) Why we have a userName parameter ? Looks like not used. 2) Would we rewrite it for better reading and extension. Suggest: handleJWTCookie(jwtToken) { boolean validated = validateToken(jwtToken); ... } validateToken(jwtToken) { validateSignature(jwtToken); validateAudiences(jwtToken); validateExpiration(jwtToken); } Other effort like HADOOP-10959 can easily override validateToken method. 3) I thought the coding style here might be a little different from the project. 11. Only userName is used as the result of web sso, but I'm not sure that's enough to ensure its uniqueness. 12. Ref. below, the message isn't correct. By the way, looks like we only support PEM format. + if (pem.startsWith(PEM_HEADER)) { + message = "CertificateException - do not include PEM header and footer" ; + }
          Hide
          lmccay Larry McCay added a comment -

          Thanks for the review, Kai.
          I will address as many of the comments that you raise as appropriate for this iteration and provide a new patch.

          I'll try and address our comments/questions here to help clarify:

          • I believe that updating both poms is necessary in order to avoid putting the version of the new dependency in the hadoop-auth module. They get spelled out specifically in hadoop-project and referenced in the other modules. NOTE: bouncy castle is being excluded for this patch. There is nothing in the WebSSO usecase that requires it.
          • I agree with your assertion that the token should only be sent over SSL. This should be managed by the authentication server that creates the cookie. It must be able to be set to Secure only.
          • For WebSSO - I see the use of a cookie as fine and it aligns with the current usage of the hadoop.auth token in Hadoop. At some point later we could add a POST profile if there is a need.
          • I will limit the use of the word cookie as you suggest and ensure that it is just one way to acquire the token from the request. I already had this in mind for a later improvement - as I want to add support for JWT as a bearer token as well.
          • The bearer token usecase I mentioned above would be useful REST calls and is what I have in mind there. However, this patch does not introduce support for webhdfs or other REST servers yet. We will tackle them after this gets in.
          • Since the intent of the JWT token at this point is to allow for the creation of the hadoop.auth cookie, it can and should have a shorter lived expiration date. Just long enough to make sure that the normal hadoop cookie can be acquired. Tying their lifetimes together wouldn't add any value there.
          • I will refactor the handleJWTToken as you suggest
          • userName will be whatever the authentication server provides in the JWT. It will only ever be as unique as asserted by the issuer.
          • The message regarding the header and footer actually is correct. The required configuration is the PEM encoded certificate without the header and footer. This is actually the same way that public keys are configured in shibboleth and works well. The wording of the message needs to be improved to make sure that it is clear.
          • Yes, we only support a PEM configuration element for the public key in this patch. There is however a method for setting the RSAPublicKey directly that is only used in tests at the moment. We can add KeyProvider API support for getting the public key later - if that makes sense. I actually find the configuration approach preferable. It can easily be added through a management console, it is a public key - so the file permissions protection for the config file is plenty of protection.

          I will post a new patch today.

          Thanks again!

          Show
          lmccay Larry McCay added a comment - Thanks for the review, Kai. I will address as many of the comments that you raise as appropriate for this iteration and provide a new patch. I'll try and address our comments/questions here to help clarify: I believe that updating both poms is necessary in order to avoid putting the version of the new dependency in the hadoop-auth module. They get spelled out specifically in hadoop-project and referenced in the other modules. NOTE: bouncy castle is being excluded for this patch. There is nothing in the WebSSO usecase that requires it. I agree with your assertion that the token should only be sent over SSL. This should be managed by the authentication server that creates the cookie. It must be able to be set to Secure only. For WebSSO - I see the use of a cookie as fine and it aligns with the current usage of the hadoop.auth token in Hadoop. At some point later we could add a POST profile if there is a need. I will limit the use of the word cookie as you suggest and ensure that it is just one way to acquire the token from the request. I already had this in mind for a later improvement - as I want to add support for JWT as a bearer token as well. The bearer token usecase I mentioned above would be useful REST calls and is what I have in mind there. However, this patch does not introduce support for webhdfs or other REST servers yet. We will tackle them after this gets in. Since the intent of the JWT token at this point is to allow for the creation of the hadoop.auth cookie, it can and should have a shorter lived expiration date. Just long enough to make sure that the normal hadoop cookie can be acquired. Tying their lifetimes together wouldn't add any value there. I will refactor the handleJWTToken as you suggest userName will be whatever the authentication server provides in the JWT. It will only ever be as unique as asserted by the issuer. The message regarding the header and footer actually is correct. The required configuration is the PEM encoded certificate without the header and footer. This is actually the same way that public keys are configured in shibboleth and works well. The wording of the message needs to be improved to make sure that it is clear. Yes, we only support a PEM configuration element for the public key in this patch. There is however a method for setting the RSAPublicKey directly that is only used in tests at the moment. We can add KeyProvider API support for getting the public key later - if that makes sense. I actually find the configuration approach preferable. It can easily be added through a management console, it is a public key - so the file permissions protection for the config file is plenty of protection. I will post a new patch today. Thanks again!
          Hide
          lmccay Larry McCay added a comment -

          New patch revision that addresses review comments from Kai Zheng.

          Show
          lmccay Larry McCay added a comment - New patch revision that addresses review comments from Kai Zheng .
          Hide
          hadoopqa Hadoop QA added a comment -

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

          +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 6 warning messages.
          See https://builds.apache.org/job/PreCommit-HADOOP-Build/5946//artifact/patchprocess/diffJavadocWarnings.txt for details.

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

          +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) 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.

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

          This message is automatically generated.

          Show
          hadoopqa Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12704694/HADOOP-11717-3.patch against trunk revision bc9cb3e. +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 6 warning messages. See https://builds.apache.org/job/PreCommit-HADOOP-Build/5946//artifact/patchprocess/diffJavadocWarnings.txt for details. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 2.0.3) 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. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/5946//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/5946//console This message is automatically generated.
          Hide
          wheat9 Haohui Mai added a comment -

          I'm not an expert in the area, but got a couple questions and would appreciate some explanations:

          • How far off if I need to implement the OAuth 2.0 protocol?
          • Does it mean that JWT tokens are the format of auth cookie in Hadoop SSO cases? Many SSO implementation talks the OAuth 2.0, it doesn't seem that it specifies the token has to be in JSON.
          • Can you separate the mechanism (if there're no authentication token, then redirect) and the real implementation (JWT tokens)? I don't really follow why RSA / PEM are required if SSO is the end-goal – looks like that only integrity is required here, and a simple HMAC would work as what we did in Hadoop delegation token.

          Thanks.

          Show
          wheat9 Haohui Mai added a comment - I'm not an expert in the area, but got a couple questions and would appreciate some explanations: How far off if I need to implement the OAuth 2.0 protocol? Does it mean that JWT tokens are the format of auth cookie in Hadoop SSO cases? Many SSO implementation talks the OAuth 2.0, it doesn't seem that it specifies the token has to be in JSON. Can you separate the mechanism (if there're no authentication token, then redirect) and the real implementation (JWT tokens)? I don't really follow why RSA / PEM are required if SSO is the end-goal – looks like that only integrity is required here, and a simple HMAC would work as what we did in Hadoop delegation token. Thanks.
          Hide
          lmccay Larry McCay added a comment -

          Hi Haohui Mai - good questions. I will try and address them.

          First a couple background point that may help in general:

          • JWT is a token that is gaining more and more acceptance as a great token to normalize authentication events that are a result of many different authentication servers/mechanisms. In fact, a jwt specific OAuth 2 profile is available: http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
          • This patch does not change the existing Hadoop sso tokens. It introduces a specific type of token - JWT - as a new mechanism for acquiring the hadoop.auth cookie. We shouldn't try and boil the ocean and do everything for everyone in this handler.
          • This patch provides a very specific behavior - WebSSO through redirect that results in a JWT token from which the current hadoop auth cookie is created. It also tries to make it possible for extensions to provide new implementations for various aspects of the token validation. That said, this is just a one option to be available where it is appropriate. It is certainly not being made the default option or a required one.
          • It will likely be extended to add support for other ways to get a JWT from the request at some point in the future.

          1. OAuth 2.0 - there is nothing about this patch that precludes us from adding a similar handler for OAuth or any other protocol as we see fit. This patch introduces support for WebSSO type flows for UIs. Perhaps, OAuth 2.0 can be accommodated within this flow where it would result in a JWT token or perhaps we would add another handler altogether.

          2. As I described about the auth cookie in Hadoop continues to be the existing cookie - this patch provides a new token that can be used like a credential for acquiring a hadoop auth cookie. We aren't changing how things currently work - just providing an alternative that allows for certain integration capabilities.

          3. I don't see any real need to separate the redirecting capability of this patch from the specific type of token for a couple reasons: the redirecting capability alone is very simple and doesn't require an abstract or base class, the JWT processing available in the nimbus-jose-jwt library is quite succinct and easily understood and we can always refactor them apart later if the need arises. In the absence of other usecases, I think it is premature to provide the separation.

          4. HMAC vs RSA - this is an interesting topic. This really comes down to HMAC vs PKI. While either can be used to provide integrity checking and establish trust relationships, HMAC requires a shared secret between the parties. This means that the secret must be available to both the signer and the consumer of the HMAC. In Hadoop this means that it must be available to many different processes/system users. The more such a secret is available the more easily it is compromised. PKI on the other hand only requires the public key be distributed to the consumers. It doesn't have to be kept completely secret like a shared secret because - it is public. You just have to know that you got it from a trusted party. An admin setting the PEM as a configuration element provides exactly that level of trust without requiring a secret distribution mechanism and encrypted storage of the key. I am actually considering providing a signer secret provider and some refactoring that is based on PKI as well. This would provide the same benefits for distribution and storage for the delegation and hadoop auth tokens.

          I hope that these points explain my design choices here. I plan to provide a design document for this improvement that spells out the configuration and implementation clearly.

          Thank you for the very good questions!

          Show
          lmccay Larry McCay added a comment - Hi Haohui Mai - good questions. I will try and address them. First a couple background point that may help in general: JWT is a token that is gaining more and more acceptance as a great token to normalize authentication events that are a result of many different authentication servers/mechanisms. In fact, a jwt specific OAuth 2 profile is available: http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04 This patch does not change the existing Hadoop sso tokens. It introduces a specific type of token - JWT - as a new mechanism for acquiring the hadoop.auth cookie. We shouldn't try and boil the ocean and do everything for everyone in this handler. This patch provides a very specific behavior - WebSSO through redirect that results in a JWT token from which the current hadoop auth cookie is created. It also tries to make it possible for extensions to provide new implementations for various aspects of the token validation. That said, this is just a one option to be available where it is appropriate. It is certainly not being made the default option or a required one. It will likely be extended to add support for other ways to get a JWT from the request at some point in the future. 1. OAuth 2.0 - there is nothing about this patch that precludes us from adding a similar handler for OAuth or any other protocol as we see fit. This patch introduces support for WebSSO type flows for UIs. Perhaps, OAuth 2.0 can be accommodated within this flow where it would result in a JWT token or perhaps we would add another handler altogether. 2. As I described about the auth cookie in Hadoop continues to be the existing cookie - this patch provides a new token that can be used like a credential for acquiring a hadoop auth cookie. We aren't changing how things currently work - just providing an alternative that allows for certain integration capabilities. 3. I don't see any real need to separate the redirecting capability of this patch from the specific type of token for a couple reasons: the redirecting capability alone is very simple and doesn't require an abstract or base class, the JWT processing available in the nimbus-jose-jwt library is quite succinct and easily understood and we can always refactor them apart later if the need arises. In the absence of other usecases, I think it is premature to provide the separation. 4. HMAC vs RSA - this is an interesting topic. This really comes down to HMAC vs PKI. While either can be used to provide integrity checking and establish trust relationships, HMAC requires a shared secret between the parties. This means that the secret must be available to both the signer and the consumer of the HMAC. In Hadoop this means that it must be available to many different processes/system users. The more such a secret is available the more easily it is compromised. PKI on the other hand only requires the public key be distributed to the consumers. It doesn't have to be kept completely secret like a shared secret because - it is public. You just have to know that you got it from a trusted party. An admin setting the PEM as a configuration element provides exactly that level of trust without requiring a secret distribution mechanism and encrypted storage of the key. I am actually considering providing a signer secret provider and some refactoring that is based on PKI as well. This would provide the same benefits for distribution and storage for the delegation and hadoop auth tokens. I hope that these points explain my design choices here. I plan to provide a design document for this improvement that spells out the configuration and implementation clearly. Thank you for the very good questions!
          Hide
          lmccay Larry McCay added a comment -

          Javadoc warnings

          Show
          lmccay Larry McCay added a comment - Javadoc warnings
          Hide
          lmccay Larry McCay added a comment -

          Addressing the found javadoc warnings with a new patch.

          Show
          lmccay Larry McCay added a comment - Addressing the found javadoc warnings with a new patch.
          Hide
          hadoopqa Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12704793/HADOOP-11717-4.patch
          against trunk revision 3da9a97.

          +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. There were no new javadoc warning messages.

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

          +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) 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.

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

          This message is automatically generated.

          Show
          hadoopqa Hadoop QA added a comment - +1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12704793/HADOOP-11717-4.patch against trunk revision 3da9a97. +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 . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 2.0.3) 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. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/5951//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/5951//console This message is automatically generated.
          Hide
          drankye Kai Zheng added a comment -

          Thanks Larry McCay for the update.

          It looks nice. Just a minor reminding, wouldn't you double check the coding style and formats ?

          Show
          drankye Kai Zheng added a comment - Thanks Larry McCay for the update. It looks nice. Just a minor reminding, wouldn't you double check the coding style and formats ?
          Hide
          lmccay Larry McCay added a comment -

          Kai Zheng - Can you provide more information? It seems in line with existing handlers in the module - to me.

          Show
          lmccay Larry McCay added a comment - Kai Zheng - Can you provide more information? It seems in line with existing handlers in the module - to me.
          Hide
          lmccay Larry McCay added a comment -

          I see curly brace placement is different - though it is a bit mixed in the existing code base.
          I can address that.

          Kai Zheng - if you see anything else can you let me know - so that we can maybe avoid another iteration?
          Thanks!

          Show
          lmccay Larry McCay added a comment - I see curly brace placement is different - though it is a bit mixed in the existing code base. I can address that. Kai Zheng - if you see anything else can you let me know - so that we can maybe avoid another iteration? Thanks!
          Hide
          drankye Kai Zheng added a comment -

          OK, I'll provide more comments today late my side. Thanks !

          Show
          drankye Kai Zheng added a comment - OK, I'll provide more comments today late my side. Thanks !
          Hide
          lmccay Larry McCay added a comment -

          I turned on my IDE hadoop profile. Don't worry about more of a review.
          Thanks, Kai!

          Show
          lmccay Larry McCay added a comment - I turned on my IDE hadoop profile. Don't worry about more of a review. Thanks, Kai!
          Hide
          lmccay Larry McCay added a comment -

          Applied hadoop formatting profile from IDE to fix formatting issues. Attaching new patch.

          Show
          lmccay Larry McCay added a comment - Applied hadoop formatting profile from IDE to fix formatting issues. Attaching new patch.
          Hide
          hadoopqa Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12705066/HADOOP-11717-5.patch
          against trunk revision 7179f94.

          +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. There were no new javadoc warning messages.

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

          +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) 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.

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

          This message is automatically generated.

          Show
          hadoopqa Hadoop QA added a comment - +1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12705066/HADOOP-11717-5.patch against trunk revision 7179f94. +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 . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 2.0.3) 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. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/5957//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/5957//console This message is automatically generated.
          Hide
          drankye Kai Zheng added a comment -

          More comments to complete the review, mainly about tests.
          1. The new handler looks little heavier to me. One thing we can do for now is to have a utility class like JwtTokenUtil and remove at least getPublicKey related logic and variables there. So some related tests like testValidPEM will not need a handler instance. How about having parsePublicKey (instead of getPublicKey), parseAudiences, and parseJwtToken (even trivial, restore JWT from a string like from cookie) for the new utility class if it sounds better to have ?
          2. It would be good not to couple the new test with KerberosSecurityTestcase since all the test cases won't relate to Kerberos at all.
          3. For all the handler really logic tests, better to move the following to setup or teardown.

          JWTRedirectAuthenticationHandler handler = new JWTRedirectAuthenticationHandler();
          ...
          handler.destroy();
          

          4. All the handler logic tests are different in token preparing. It's possible to have the following in a function where token is a parameter to avoid repeating.

          +      Properties props = getProperties();
          +      handler.init(props);
          +
          +      SignedJWT jwt = getJWT("bob", new Date(new Date().getTime() + 5000),
          +          privateKey);
          +
          +      Cookie cookie = new Cookie("hadoop-jwt", jwt.serialize());
          +      HttpServletRequest request = Mockito.mock(HttpServletRequest.class);
          +      Mockito.when(request.getCookies()).thenReturn(new Cookie[] { cookie });
          +      Mockito.when(request.getRequestURL()).thenReturn(
          +          new StringBuffer(SERVICE_URL));
          +      HttpServletResponse response = Mockito.mock(HttpServletResponse.class);
          +      Mockito.when(response.encodeRedirectURL(SERVICE_URL)).thenReturn(
          +          SERVICE_URL);
          +
          +      AuthenticationToken token = handler.alternateAuthenticate(request,
          +          response);
          

          5. In the tests, we have repeated values like "bar", "bob" here and there. How about having variables for them ?
          6. In the following codes, aud and sigInput aren't really used.

          +    List<String> aud = new ArrayList<String>();
          +    aud.add("bar");
          +    claimsSet.setAudience("bar");
          +
          +    JWSHeader header = new JWSHeader.Builder(JWSAlgorithm.RS256).build();
          +
          +    SignedJWT signedJWT = new SignedJWT(header, claimsSet);
          +    Base64URL sigInput = Base64URL.encode(signedJWT.getSigningInput());
          +    JWSSigner signer = new RSASSASigner(privateKey);
          +
          +    signedJWT.sign(signer);
          +
          +    return signedJWT;
          
          Show
          drankye Kai Zheng added a comment - More comments to complete the review, mainly about tests. 1. The new handler looks little heavier to me. One thing we can do for now is to have a utility class like JwtTokenUtil and remove at least getPublicKey related logic and variables there. So some related tests like testValidPEM will not need a handler instance. How about having parsePublicKey (instead of getPublicKey ), parseAudiences , and parseJwtToken (even trivial, restore JWT from a string like from cookie) for the new utility class if it sounds better to have ? 2. It would be good not to couple the new test with KerberosSecurityTestcase since all the test cases won't relate to Kerberos at all. 3. For all the handler really logic tests, better to move the following to setup or teardown . JWTRedirectAuthenticationHandler handler = new JWTRedirectAuthenticationHandler(); ... handler.destroy(); 4. All the handler logic tests are different in token preparing. It's possible to have the following in a function where token is a parameter to avoid repeating. + Properties props = getProperties(); + handler.init(props); + + SignedJWT jwt = getJWT( "bob" , new Date( new Date().getTime() + 5000), + privateKey); + + Cookie cookie = new Cookie( "hadoop-jwt" , jwt.serialize()); + HttpServletRequest request = Mockito.mock(HttpServletRequest.class); + Mockito.when(request.getCookies()).thenReturn( new Cookie[] { cookie }); + Mockito.when(request.getRequestURL()).thenReturn( + new StringBuffer (SERVICE_URL)); + HttpServletResponse response = Mockito.mock(HttpServletResponse.class); + Mockito.when(response.encodeRedirectURL(SERVICE_URL)).thenReturn( + SERVICE_URL); + + AuthenticationToken token = handler.alternateAuthenticate(request, + response); 5. In the tests, we have repeated values like "bar", "bob" here and there. How about having variables for them ? 6. In the following codes, aud and sigInput aren't really used. + List< String > aud = new ArrayList< String >(); + aud.add( "bar" ); + claimsSet.setAudience( "bar" ); + + JWSHeader header = new JWSHeader.Builder(JWSAlgorithm.RS256).build(); + + SignedJWT signedJWT = new SignedJWT(header, claimsSet); + Base64URL sigInput = Base64URL.encode(signedJWT.getSigningInput()); + JWSSigner signer = new RSASSASigner(privateKey); + + signedJWT.sign(signer); + + return signedJWT;
          Hide
          wheat9 Haohui Mai added a comment -

          Thanks Larry for the answers. I wonder, are there any common infrastructures between JWT token and a potential OAuth 2.0 implementation? It would be great to separate the common infrastructures into a separate patch.

          Show
          wheat9 Haohui Mai added a comment - Thanks Larry for the answers. I wonder, are there any common infrastructures between JWT token and a potential OAuth 2.0 implementation? It would be great to separate the common infrastructures into a separate patch.
          Hide
          lmccay Larry McCay added a comment -

          Haohui Mai - There is only one source file here.
          There is no infrastructure beyond the preexisting AltKerberosAuthenticationHandler.

          I certainly agree that code reuse would be great and if/when we add an OAuth handler we should determine if we should refactor. In the meantime, there is no point in prematurely doing so in a way that may not work when we go to use it anyway.

          Show
          lmccay Larry McCay added a comment - Haohui Mai - There is only one source file here. There is no infrastructure beyond the preexisting AltKerberosAuthenticationHandler. I certainly agree that code reuse would be great and if/when we add an OAuth handler we should determine if we should refactor. In the meantime, there is no point in prematurely doing so in a way that may not work when we go to use it anyway.
          Hide
          lmccay Larry McCay added a comment -

          Need to handle validation failures differently. Currently, this patch results in a 403 with the validation failure message. Need to log this and rechallenge instead.

          Show
          lmccay Larry McCay added a comment - Need to handle validation failures differently. Currently, this patch results in a 403 with the validation failure message. Need to log this and rechallenge instead.
          Hide
          lmccay Larry McCay added a comment -

          Attaching new patch - it addresses:

          • some minor changes to tests as requested by Kai Zheng
          • separation of certificate PEM parsing into CertificateUtil class
          • more appropriate handling of token validation errors to reauthenticate rather than return a 403

          I think that any additional refactoring can be done as a result of needing to leverage common code.

          Show
          lmccay Larry McCay added a comment - Attaching new patch - it addresses: some minor changes to tests as requested by Kai Zheng separation of certificate PEM parsing into CertificateUtil class more appropriate handling of token validation errors to reauthenticate rather than return a 403 I think that any additional refactoring can be done as a result of needing to leverage common code.
          Hide
          hadoopqa Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12707807/HADOOP-11717-6.patch
          against trunk revision 05499b1.

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

          +1 tests included. The patch appears to include 2 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/6015//console

          This message is automatically generated.

          Show
          hadoopqa Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12707807/HADOOP-11717-6.patch against trunk revision 05499b1. +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 2 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/6015//console This message is automatically generated.
          Hide
          lmccay Larry McCay added a comment -

          Resubmitting the patch - shouldn't have caused the build to fail...

          Show
          lmccay Larry McCay added a comment - Resubmitting the patch - shouldn't have caused the build to fail...
          Hide
          lmccay Larry McCay added a comment -

          removed extraneous imports in test which were causing a build failure.

          Show
          lmccay Larry McCay added a comment - removed extraneous imports in test which were causing a build failure.
          Hide
          hadoopqa Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12707839/HADOOP-11717-7.patch
          against trunk revision 05499b1.

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

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

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

          +1 javadoc. There were no new javadoc warning messages.

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

          -1 findbugs. The patch appears to introduce 2 new Findbugs (version 2.0.3) 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.

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

          This message is automatically generated.

          Show
          hadoopqa Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12707839/HADOOP-11717-7.patch against trunk revision 05499b1. +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 2 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. -1 findbugs . The patch appears to introduce 2 new Findbugs (version 2.0.3) 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. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/6016//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HADOOP-Build/6016//artifact/patchprocess/newPatchFindbugsWarningshadoop-auth.html Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/6016//console This message is automatically generated.
          Hide
          lmccay Larry McCay added a comment -

          Those findbug warnings are unrelated to this patch.

          Owen O'Malley - can you give this a review when you get a chance?

          Show
          lmccay Larry McCay added a comment - Those findbug warnings are unrelated to this patch. Owen O'Malley - can you give this a review when you get a chance?
          Hide
          drankye Kai Zheng added a comment -

          Larry McCay, looks like we don't consider token encryption and decryption, right ?

          It's good to get this in since it gets the job well done. As I mentioned in this JIRA earlier and discussed in HADOOP-11766, we also have bunch of codes related this in TokenAuth related efforts. We're refining our existing codes and will break them down into smaller ones. We would incorporate this part rather than duplicating something. As already widely discussed and agreed, we need more generic token APIs and common pluggable and configurable facilities like token encoder, decoder and validation. We will refine our codes plus this work in tasks in HADOOP-11766. Thanks for the work !

          Show
          drankye Kai Zheng added a comment - Larry McCay , looks like we don't consider token encryption and decryption, right ? It's good to get this in since it gets the job well done. As I mentioned in this JIRA earlier and discussed in HADOOP-11766 , we also have bunch of codes related this in TokenAuth related efforts. We're refining our existing codes and will break them down into smaller ones. We would incorporate this part rather than duplicating something. As already widely discussed and agreed, we need more generic token APIs and common pluggable and configurable facilities like token encoder, decoder and validation. We will refine our codes plus this work in tasks in HADOOP-11766 . Thanks for the work !
          Hide
          lmccay Larry McCay added a comment -

          Hey Kai Zheng - yeah, there is no reason to encrypt and decrypt here - the assumption is that they are to be protected with transport security.

          Show
          lmccay Larry McCay added a comment - Hey Kai Zheng - yeah, there is no reason to encrypt and decrypt here - the assumption is that they are to be protected with transport security.
          Hide
          owen.omalley Owen O'Malley added a comment -

          I think this looks good. +1

          Show
          owen.omalley Owen O'Malley added a comment - I think this looks good. +1
          Hide
          jiajia Jiajia Li added a comment -

          Hi, it has error when I try to apply this patch to trunk, can you update the patch?

          patching file pom.xml
          Hunk #1 FAILED at 98.
          1 out of 1 hunk FAILED – saving rejects to file pom.xml.rej
          patching file JWTRedirectAuthenticationHandler.java
          patching file CertificateUtil.java
          patching file TestJWTRedirectAuthentictionHandler.java
          patching file TestCertificateUtil.java
          patching file pom.xml
          Hunk #1 FAILED at 803.
          1 out of 1 hunk FAILED – saving rejects to file pom.xml.rej

          Show
          jiajia Jiajia Li added a comment - Hi, it has error when I try to apply this patch to trunk, can you update the patch? patching file pom.xml Hunk #1 FAILED at 98. 1 out of 1 hunk FAILED – saving rejects to file pom.xml.rej patching file JWTRedirectAuthenticationHandler.java patching file CertificateUtil.java patching file TestJWTRedirectAuthentictionHandler.java patching file TestCertificateUtil.java patching file pom.xml Hunk #1 FAILED at 803. 1 out of 1 hunk FAILED – saving rejects to file pom.xml.rej
          Hide
          lmccay Larry McCay added a comment -

          Will do - thanks!

          Show
          lmccay Larry McCay added a comment - Will do - thanks!
          Hide
          lmccay Larry McCay added a comment -

          Fixed the prefix issue with the previous patch.
          It should apply fine now.

          Show
          lmccay Larry McCay added a comment - Fixed the prefix issue with the previous patch. It should apply fine now.
          Hide
          hadoopqa Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12709235/HADOOP-11717-8.patch
          against trunk revision 72f6bd4.

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

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

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

          +1 javadoc. There were no new javadoc warning messages.

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

          +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) 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.

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

          This message is automatically generated.

          Show
          hadoopqa Hadoop QA added a comment - +1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12709235/HADOOP-11717-8.patch against trunk revision 72f6bd4. +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 2 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 2.0.3) 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. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/6059//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/6059//console This message is automatically generated.
          Hide
          lmccay Larry McCay added a comment -

          Attached overview and configuration details for this JWT based WebSSO handler.

          Show
          lmccay Larry McCay added a comment - Attached overview and configuration details for this JWT based WebSSO handler.
          Hide
          hadoopqa Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12709428/RedirectingWebSSOwithJWTforHadoopWebUIs.pdf
          against trunk revision ef591b1.

          -1 patch. The patch command could not apply the patch.

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

          This message is automatically generated.

          Show
          hadoopqa Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12709428/RedirectingWebSSOwithJWTforHadoopWebUIs.pdf against trunk revision ef591b1. -1 patch . The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/6063//console This message is automatically generated.
          Hide
          lmccay Larry McCay added a comment -

          Oops - tried to test the pdf attachment...
          Failures unrelated to actual patch.

          Show
          lmccay Larry McCay added a comment - Oops - tried to test the pdf attachment... Failures unrelated to actual patch.
          Hide
          drankye Kai Zheng added a comment -

          Thanks for the update.

          there is no reason to encrypt and decrypt here - the assumption is that they are to be protected with transport security.

          Sorry for my late response. I don't quite agree with this, as transport security is used to protect token from being leaked, and the encryption layer in token itself can be used to protect sensitive identity privacy, which means if someone loses his/her token, he/she won't suffer from exposing any sensitive credential identity attributes. I thought that's why JWE is defined and required. I understand in your case/requirement/scenario you may not use encryption feature, but it can be useful for others. I do think we can leave this aspect for future consideration, like tasks in HADOOP-11766.

          I missed to mention another point. Why we couple this with AltKerberosAuthenticationHandler? I thought a dedicated authentication handler like AuthTokenAuthenticationHandler may make more sense. Still, this may be handled separately if sounds good.

          Another point made by Haohui Mai here, which was also widely discussed before, it would be good to have a generic token abstract from JWT stuff. Again, I would follow up on this in HADOOP-11766 tasks.

          We still need to think about how to apply this new mechanism across all the web interfaces for HDFS and YARN. Will fire another task for this.

          Related to above points, to make the work more general, I suggest we change the following configuration items.
          authentication.provider.url => token.authentication.provider.url
          public.key.pem => token.signature.publickey;
          expected.jwt.audiences => expected.token.audiences;

          Maybe it's a little late to mention these. What I'm worrying about is once we have this in the trunk, we're then not able to enhance or follow up easily in the following. Any good idea for the concern? Thanks!

          Show
          drankye Kai Zheng added a comment - Thanks for the update. there is no reason to encrypt and decrypt here - the assumption is that they are to be protected with transport security. Sorry for my late response. I don't quite agree with this, as transport security is used to protect token from being leaked, and the encryption layer in token itself can be used to protect sensitive identity privacy, which means if someone loses his/her token, he/she won't suffer from exposing any sensitive credential identity attributes. I thought that's why JWE is defined and required. I understand in your case/requirement/scenario you may not use encryption feature, but it can be useful for others. I do think we can leave this aspect for future consideration, like tasks in HADOOP-11766 . I missed to mention another point. Why we couple this with AltKerberosAuthenticationHandler ? I thought a dedicated authentication handler like AuthTokenAuthenticationHandler may make more sense. Still, this may be handled separately if sounds good. Another point made by Haohui Mai here, which was also widely discussed before, it would be good to have a generic token abstract from JWT stuff. Again, I would follow up on this in HADOOP-11766 tasks. We still need to think about how to apply this new mechanism across all the web interfaces for HDFS and YARN. Will fire another task for this. Related to above points, to make the work more general, I suggest we change the following configuration items. authentication.provider.url => token.authentication.provider.url public.key.pem => token.signature.publickey; expected.jwt.audiences => expected.token.audiences; Maybe it's a little late to mention these. What I'm worrying about is once we have this in the trunk, we're then not able to enhance or follow up easily in the following. Any good idea for the concern? Thanks!
          Hide
          lmccay Larry McCay added a comment -

          Kai Zheng - Encryption is great where it is required. It isn't required here as the cookie should be set to HTTPOnly which will not allow access by JS inside of pages and Secure which will require it to be sent over secure channels - it is otherwise managed by the browser.

          The reason that it extends AltKerberosAuthenticationHandler is to accommodate non-browser clients - of which there are a few. Requiring all clients to the same endpoints to be able to handle a redirect and challenge - typically with a form - will not work. Also, changing all these clients to acquire a token that is more appropriate for their usage pattern is outside the scope of this patch. This usage pattern will be introduced for such clients in a later effort.

          As I answered previously, there is no need to pull the JWT code into a generic token handling utility at this point and there is no value in doing so prematurely. Slowing progress here in order to do this now - to meet the needs of no other consumers would be artificial and unnecessary.

          This handler already works for HDFS and YARN UIs - I have tested them.

          I see little value in the configuration element changes that you propose:
          Adding token to authentication.provider.url - doesn't make it more general.
          Changing public.key.pem to token.signature.publickey - loses the self descriptive nature of it being a pem representation.
          Replacing JWT with token does make it more general but this handler really is about JWT support.

          I will consider changing these names a bit more but don't see any reason that they can't go in the way they are.
          We will certainly want to have them nailed down before backporting the patch to another branch.

          Show
          lmccay Larry McCay added a comment - Kai Zheng - Encryption is great where it is required. It isn't required here as the cookie should be set to HTTPOnly which will not allow access by JS inside of pages and Secure which will require it to be sent over secure channels - it is otherwise managed by the browser. The reason that it extends AltKerberosAuthenticationHandler is to accommodate non-browser clients - of which there are a few. Requiring all clients to the same endpoints to be able to handle a redirect and challenge - typically with a form - will not work. Also, changing all these clients to acquire a token that is more appropriate for their usage pattern is outside the scope of this patch. This usage pattern will be introduced for such clients in a later effort. As I answered previously, there is no need to pull the JWT code into a generic token handling utility at this point and there is no value in doing so prematurely. Slowing progress here in order to do this now - to meet the needs of no other consumers would be artificial and unnecessary. This handler already works for HDFS and YARN UIs - I have tested them. I see little value in the configuration element changes that you propose: Adding token to authentication.provider.url - doesn't make it more general. Changing public.key.pem to token.signature.publickey - loses the self descriptive nature of it being a pem representation. Replacing JWT with token does make it more general but this handler really is about JWT support. I will consider changing these names a bit more but don't see any reason that they can't go in the way they are. We will certainly want to have them nailed down before backporting the patch to another branch.
          Hide
          drankye Kai Zheng added a comment -

          Encryption is great where it is required. It isn't required here ...

          This work should not just solve your case. We should not suppose all JWT tokens are issued as you expected. Assume some JWT token with encrypted attributes, how would this handle it? As I said, this can be followed up later, but you disagreed at all.

          The reason that it extends AltKerberosAuthenticationHandler is to accommodate non-browser clients...

          I see no reason we have to couple with AltKerberosAuthenticationHandler. It looks rather complicated, even so why we won't have a dedicated handler to handle all the cases? Wouldn't it be easier? If I missed anything please correct me. Thanks.

          As I answered previously, there is no need to pull the JWT code into a generic token handling utility at this point...

          I agree. I'm not saying we should do this right now. I will follow up in other issues. Agree?

          This handler already works for HDFS and YARN UIs - I have tested them.

          Sounds good. Did you get the SSO effect across all the UIs, say only ONE time redirection to the authentication provider url happened in a reasonable time when you go here and there? How about web HDFS?

          I see little value in the configuration element changes...

          I thought it's worth to pay attention to introduce new configuration items. Once it's used, we'll need to maintain it.
          public.key.pem to token.signature.publickey, so it will be easy to add another key, token.encryption.privatekey.

          Replacing JWT with token does make it more general but this handler really is about JWT support

          I thought you agreed to have general token stuff in some time in future even not now, so why won't we use more general configuration name here right now?

          Show
          drankye Kai Zheng added a comment - Encryption is great where it is required. It isn't required here ... This work should not just solve your case. We should not suppose all JWT tokens are issued as you expected. Assume some JWT token with encrypted attributes, how would this handle it? As I said, this can be followed up later, but you disagreed at all. The reason that it extends AltKerberosAuthenticationHandler is to accommodate non-browser clients... I see no reason we have to couple with AltKerberosAuthenticationHandler. It looks rather complicated, even so why we won't have a dedicated handler to handle all the cases? Wouldn't it be easier? If I missed anything please correct me. Thanks. As I answered previously, there is no need to pull the JWT code into a generic token handling utility at this point... I agree. I'm not saying we should do this right now. I will follow up in other issues. Agree? This handler already works for HDFS and YARN UIs - I have tested them. Sounds good. Did you get the SSO effect across all the UIs, say only ONE time redirection to the authentication provider url happened in a reasonable time when you go here and there? How about web HDFS? I see little value in the configuration element changes... I thought it's worth to pay attention to introduce new configuration items. Once it's used, we'll need to maintain it. public.key.pem to token.signature.publickey, so it will be easy to add another key, token.encryption.privatekey. Replacing JWT with token does make it more general but this handler really is about JWT support I thought you agreed to have general token stuff in some time in future even not now, so why won't we use more general configuration name here right now?
          Hide
          owen.omalley Owen O'Malley added a comment -

          I just committed this. Thanks, Larry!

          Show
          owen.omalley Owen O'Malley added a comment - I just committed this. Thanks, Larry!
          Hide
          owen.omalley Owen O'Malley added a comment -

          I think this is good to go. If we want to generalize it further when we have additional use cases to support, we can do that. This just provides a plugin for web sso that is useful to users that don't want to use spnego for web ui.

          Show
          owen.omalley Owen O'Malley added a comment - I think this is good to go. If we want to generalize it further when we have additional use cases to support, we can do that. This just provides a plugin for web sso that is useful to users that don't want to use spnego for web ui.
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Hadoop-trunk-Commit #7518 (See https://builds.apache.org/job/Hadoop-trunk-Commit/7518/)
          HADOOP-11717. Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49)

          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java
          • hadoop-common-project/hadoop-common/CHANGES.txt
          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java
          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java
          • hadoop-common-project/hadoop-auth/pom.xml
          • hadoop-project/pom.xml
          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Hadoop-trunk-Commit #7518 (See https://builds.apache.org/job/Hadoop-trunk-Commit/7518/ ) HADOOP-11717 . Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49) hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java hadoop-common-project/hadoop-common/CHANGES.txt hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java hadoop-common-project/hadoop-auth/pom.xml hadoop-project/pom.xml hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
          Hide
          lmccay Larry McCay added a comment -

          There may very well be usecases where encryption is necessary. I didn't mean to say that it is never needed.
          This handler is not trying to do anymore than it does.

          Keep in mind that as a pluggable handler that this mechanism is completely replaceable with some other implementation that fits the needs of a given cluster deployment better. There is no precedence being set here that can't be replaced.

          At the same time, furthering the work done in this patch with follow up improvements is a great plan to move it forward. It is much easier than trying to do everything at once.

          As for the SSO behavior:

          Yes, I have configured the signer secrets to be alike, the cookie domain to work across UIs and the expiry of the JWT token to work in various ways across the UIs with a single redirect for authentication.

          The fact that webhdfs has a completely different authentication filter means that REST requests work as normally expected - in this case it will require SPNEGO.

          I thought you agreed to have general token stuff in some time in future even not now, so why won't we use more general configuration name here right now?

          I have no problem with a general token API. The use of a handler specific configuration element shouldn't impact this at all. It is up to the handler to pass the appropriate parameters to the API.

          Thank you for your insights and discussion here, Kai Zheng.
          We will continue to evolve this work to meet as many usecases as appropriate and have a truly useful feature set here.
          Having it align with future work will also be great.

          Show
          lmccay Larry McCay added a comment - There may very well be usecases where encryption is necessary. I didn't mean to say that it is never needed. This handler is not trying to do anymore than it does. Keep in mind that as a pluggable handler that this mechanism is completely replaceable with some other implementation that fits the needs of a given cluster deployment better. There is no precedence being set here that can't be replaced. At the same time, furthering the work done in this patch with follow up improvements is a great plan to move it forward. It is much easier than trying to do everything at once. As for the SSO behavior: Yes, I have configured the signer secrets to be alike, the cookie domain to work across UIs and the expiry of the JWT token to work in various ways across the UIs with a single redirect for authentication. The fact that webhdfs has a completely different authentication filter means that REST requests work as normally expected - in this case it will require SPNEGO. I thought you agreed to have general token stuff in some time in future even not now, so why won't we use more general configuration name here right now? I have no problem with a general token API. The use of a handler specific configuration element shouldn't impact this at all. It is up to the handler to pass the appropriate parameters to the API. Thank you for your insights and discussion here, Kai Zheng . We will continue to evolve this work to meet as many usecases as appropriate and have a truly useful feature set here. Having it align with future work will also be great.
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Yarn-trunk-Java8 #157 (See https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/157/)
          HADOOP-11717. Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49)

          • hadoop-common-project/hadoop-auth/pom.xml
          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java
          • hadoop-common-project/hadoop-common/CHANGES.txt
          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java
          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java
          • hadoop-project/pom.xml
          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Yarn-trunk-Java8 #157 (See https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/157/ ) HADOOP-11717 . Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49) hadoop-common-project/hadoop-auth/pom.xml hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java hadoop-common-project/hadoop-common/CHANGES.txt hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java hadoop-project/pom.xml hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Hdfs-trunk #2089 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/2089/)
          HADOOP-11717. Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49)

          • hadoop-common-project/hadoop-common/CHANGES.txt
          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java
          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java
          • hadoop-project/pom.xml
          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
          • hadoop-common-project/hadoop-auth/pom.xml
          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Hdfs-trunk #2089 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/2089/ ) HADOOP-11717 . Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49) hadoop-common-project/hadoop-common/CHANGES.txt hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java hadoop-project/pom.xml hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java hadoop-common-project/hadoop-auth/pom.xml hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Hdfs-trunk-Java8 #148 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/148/)
          HADOOP-11717. Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49)

          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java
          • hadoop-common-project/hadoop-common/CHANGES.txt
          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java
          • hadoop-common-project/hadoop-auth/pom.xml
          • hadoop-project/pom.xml
          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Hdfs-trunk-Java8 #148 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/148/ ) HADOOP-11717 . Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49) hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java hadoop-common-project/hadoop-common/CHANGES.txt hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java hadoop-common-project/hadoop-auth/pom.xml hadoop-project/pom.xml hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Yarn-trunk #891 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/891/)
          HADOOP-11717. Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49)

          • hadoop-common-project/hadoop-auth/pom.xml
          • hadoop-project/pom.xml
          • hadoop-common-project/hadoop-common/CHANGES.txt
          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java
          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java
          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java
          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Yarn-trunk #891 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/891/ ) HADOOP-11717 . Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49) hadoop-common-project/hadoop-auth/pom.xml hadoop-project/pom.xml hadoop-common-project/hadoop-common/CHANGES.txt hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Mapreduce-trunk-Java8 #158 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Java8/158/)
          HADOOP-11717. Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49)

          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java
          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java
          • hadoop-project/pom.xml
          • hadoop-common-project/hadoop-common/CHANGES.txt
          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java
          • hadoop-common-project/hadoop-auth/pom.xml
          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Mapreduce-trunk-Java8 #158 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Java8/158/ ) HADOOP-11717 . Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49) hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java hadoop-project/pom.xml hadoop-common-project/hadoop-common/CHANGES.txt hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java hadoop-common-project/hadoop-auth/pom.xml hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Mapreduce-trunk #2107 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/2107/)
          HADOOP-11717. Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49)

          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
          • hadoop-common-project/hadoop-common/CHANGES.txt
          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java
          • hadoop-common-project/hadoop-auth/pom.xml
          • hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java
          • hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java
          • hadoop-project/pom.xml
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Mapreduce-trunk #2107 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/2107/ ) HADOOP-11717 . Support JWT tokens for web single sign on to the Hadoop (omalley: rev ce635733144456bce6bcf8664c5850ef6b60aa49) hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java hadoop-common-project/hadoop-common/CHANGES.txt hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestJWTRedirectAuthentictionHandler.java hadoop-common-project/hadoop-auth/pom.xml hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestCertificateUtil.java hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java hadoop-project/pom.xml
          Hide
          drankye Kai Zheng added a comment -

          Thanks Larry McCay and Owen O'Malley for committing this. As I said before, it's great to have it. I realized your point only supporting the JWT token format here as it's good enough for your case right now.

          Let me open another to go for a dedicated token authentication handler for Hadoop web in general token API.

          Show
          drankye Kai Zheng added a comment - Thanks Larry McCay and Owen O'Malley for committing this. As I said before, it's great to have it. I realized your point only supporting the JWT token format here as it's good enough for your case right now. Let me open another to go for a dedicated token authentication handler for Hadoop web in general token API.

            People

            • Assignee:
              lmccay Larry McCay
              Reporter:
              lmccay Larry McCay
            • Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development