Details

    • Type: Task Task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.0.0
    • Component/s: security
    • Labels:

      Description

      As defined in TokenAuth framework, TokenAuthn as a new authentication method is to be added in current Hadoop SASL authentication framework, to allow client to access service with access token. The scope of this is as follows:

      • Add a new SASL mechanism for TokenAuthn method, including necessary SASL client and SASL server with corresponding callbacks;
      • Add TokenAuthn method in UGI and allow the method to be configured for Hadoop and the ecosystem;
      • Allow TokenAuthn method to be negotiated between client and server;
      • Define the IDP-initiated flow and SP-initiated flow in the RPC access;
      • Allow access token to be negotiated between client and server, considering both IDP-initiated case and SP-initiated case.

        Issue Links

          Activity

          Hide
          Kai Zheng added a comment -

          Initial patch adding TokenAuthn method.

          Show
          Kai Zheng added a comment - Initial patch adding TokenAuthn method.
          Hide
          Larry McCay added a comment -

          Kai - it's great to finally start seeing some code. Unfortunately, I think this patch is a bit overreaching. You should consider limiting it to the description of this JIRA. I realize that it is helpful for testing but it is less composable and harder to review this way. If you set other patches as required they can be pulled in with it for testing.

          We also need to incorporate the JsonWebToken patch that was contributed to HADOOP-9781 JWT SSO Token and Authority.
          This should be able to be utilized as the token as you described in your recent design doc. If you want to prove the ability to use something else as well then that should be a separate JIRA and patch.

          The token endpoints included in this patch should also be a separate JIRA and patch. Unless I misunderstand the HAS JIRA, they would probably be more appropriate there.

          This is a great start though. I will be reviewing this and the UGI changes today.

          Show
          Larry McCay added a comment - Kai - it's great to finally start seeing some code. Unfortunately, I think this patch is a bit overreaching. You should consider limiting it to the description of this JIRA. I realize that it is helpful for testing but it is less composable and harder to review this way. If you set other patches as required they can be pulled in with it for testing. We also need to incorporate the JsonWebToken patch that was contributed to HADOOP-9781 JWT SSO Token and Authority. This should be able to be utilized as the token as you described in your recent design doc. If you want to prove the ability to use something else as well then that should be a separate JIRA and patch. The token endpoints included in this patch should also be a separate JIRA and patch. Unless I misunderstand the HAS JIRA, they would probably be more appropriate there. This is a great start though. I will be reviewing this and the UGI changes today.
          Hide
          Daryn Sharp added a comment -

          Yes, good job! But this really big.

          At first glance, it dismays me to see TokenAuthn conditionals being riddled through the codebase. I intend to remove/generalize the required methods (like relogin()) with my overall SASL changes. The goal should be to hide the details for security from a service. This requires the security framework to be more modular (a shared goal of ours) that exposes generic methods that are non-authMethod specific.

          Show
          Daryn Sharp added a comment - Yes, good job! But this really big. At first glance, it dismays me to see TokenAuthn conditionals being riddled through the codebase. I intend to remove/generalize the required methods (like relogin()) with my overall SASL changes. The goal should be to hide the details for security from a service. This requires the security framework to be more modular (a shared goal of ours) that exposes generic methods that are non-authMethod specific.
          Hide
          Kai Zheng added a comment -

          Yes, good job! But this really big.

          Thanks! Yes, it is. I am working on breaking down the initial patch and the resulting patch for this issue would be smaller and exactly match the goals stated here.

          At first glance, it dismays me to see TokenAuthn conditionals being riddled through the codebase.

          I understand. The patch focused on adding the needed TokenAuthn method and tried to avoid irrelevant changes like UGI related ones. Depending on related improvements for UGI and SASL framework, hopefully the formal patch to be submitted here will resolve your concern.

          This requires the security framework to be more modular (a shared goal of ours) that exposes generic methods that are non-authMethod specific.

          Yes, exactly. That is my goal too.

          Show
          Kai Zheng added a comment - Yes, good job! But this really big. Thanks! Yes, it is. I am working on breaking down the initial patch and the resulting patch for this issue would be smaller and exactly match the goals stated here. At first glance, it dismays me to see TokenAuthn conditionals being riddled through the codebase. I understand. The patch focused on adding the needed TokenAuthn method and tried to avoid irrelevant changes like UGI related ones. Depending on related improvements for UGI and SASL framework, hopefully the formal patch to be submitted here will resolve your concern. This requires the security framework to be more modular (a shared goal of ours) that exposes generic methods that are non-authMethod specific. Yes, exactly. That is my goal too.
          Hide
          Larry McCay added a comment -

          It seems from various discussions that we have had on the mailing lists and at Hadoop Summit 2013 that what folks want is the ability for the services to continue to authenticate via kerberos and allow user authentication to happen via some pluggable way. I am curious what this will mean for:

          • negotiation - does the negotiation allow for selecting different methods
          • if the both choose TokenAuth (or whatever the name becomes) and they can be configured to realize the token in different ways than I guess the negotiation isn't an issue
          • the ability for a client side authentication in the SASL layer to authenticate via LDAP - for instance - and the server side in the SASL layer to authenticate via kerberos
          • do we have each authenticate and present a canonical token to each other here
          • does this described scenario necessitate changes in the current patch here
          Show
          Larry McCay added a comment - It seems from various discussions that we have had on the mailing lists and at Hadoop Summit 2013 that what folks want is the ability for the services to continue to authenticate via kerberos and allow user authentication to happen via some pluggable way. I am curious what this will mean for: negotiation - does the negotiation allow for selecting different methods if the both choose TokenAuth (or whatever the name becomes) and they can be configured to realize the token in different ways than I guess the negotiation isn't an issue the ability for a client side authentication in the SASL layer to authenticate via LDAP - for instance - and the server side in the SASL layer to authenticate via kerberos do we have each authenticate and present a canonical token to each other here does this described scenario necessitate changes in the current patch here

            People

            • Assignee:
              Kai Zheng
              Reporter:
              Kai Zheng
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:

                Development