Details

    • Type: Sub-task Sub-task
    • Status: In Progress
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: security
    • Labels:
      None

      Description

      Currently, it is not possible to hookup new/modified authentication mechanism to Hadoop.

      The task is to create an extension in hadoop to plugin new Authentication mechanism. The new authentication mechanism should have both Jaas and Sasl implementations.

      1. HADOOP-9479.patch
        38 kB
        Benoy Antony
      2. customauthentication.pdf
        36 kB
        Benoy Antony

        Issue Links

          Activity

          Hide
          Benoy Antony added a comment -

          Attached is the first version of the patch to get guidance and feedback on the general approach.
          The document briefly explains the design and test.

          Show
          Benoy Antony added a comment - Attached is the first version of the patch to get guidance and feedback on the general approach. The document briefly explains the design and test.
          Hide
          Daryn Sharp added a comment -

          I like the overall goal, but feel it's a bit rigid in only providing support for only one additional authentication method. This change dovetails with the stalled SASL work I've been doing in the subtasks for HADOOP-8779. I keep meaning to get back to it. Many of the changes were nudging the authentication scheme towards a pluggable design - you've even taken advantage of some of those changes!

          The new hadoop SASL related interfaces shouldn't be necessary. The javax SASL framework uses a factory pattern to create clients and servers via SecurityProviders. SaslPlainServer does this, although there's probably a cleaner way to do it.

          The good news is the patch should be significantly smaller if leveraging the javax framework.

          Show
          Daryn Sharp added a comment - I like the overall goal, but feel it's a bit rigid in only providing support for only one additional authentication method. This change dovetails with the stalled SASL work I've been doing in the subtasks for HADOOP-8779 . I keep meaning to get back to it. Many of the changes were nudging the authentication scheme towards a pluggable design - you've even taken advantage of some of those changes! The new hadoop SASL related interfaces shouldn't be necessary. The javax SASL framework uses a factory pattern to create clients and servers via SecurityProviders. SaslPlainServer does this, although there's probably a cleaner way to do it. The good news is the patch should be significantly smaller if leveraging the javax framework.
          Hide
          Kai Zheng added a comment -

          Hi Benoy,
          Very interesting patch! It provides custom and configurable AuthenticationProvider by wrapping SASL mechanism and JAAS module.
          Would it be better to generalize the AuthenticationProvider so that it can also fit the existing simple and Kerberos authentication method, and then refactor related code based on it? In my view it would be great to have such authentication provider that wraps client authentication and server authentication JAAS modules, the client-server SASL mechanism and related configurations together as you do, and then have concrete authentication implementations like SimpleAuthenticationProvider, KerberosAuthenticationProvider, and HADOOP-9296. In this way code and configuration related to one mechanism can be localized to the provider implementation. Another benefit would be it allows introducing additional methods in the future without the need to enumerate all of them in UserGroupInformation.AuthenticationMethod.

          Show
          Kai Zheng added a comment - Hi Benoy, Very interesting patch! It provides custom and configurable AuthenticationProvider by wrapping SASL mechanism and JAAS module. Would it be better to generalize the AuthenticationProvider so that it can also fit the existing simple and Kerberos authentication method, and then refactor related code based on it? In my view it would be great to have such authentication provider that wraps client authentication and server authentication JAAS modules, the client-server SASL mechanism and related configurations together as you do, and then have concrete authentication implementations like SimpleAuthenticationProvider, KerberosAuthenticationProvider, and HADOOP-9296 . In this way code and configuration related to one mechanism can be localized to the provider implementation. Another benefit would be it allows introducing additional methods in the future without the need to enumerate all of them in UserGroupInformation.AuthenticationMethod.
          Hide
          Daryn Sharp added a comment -

          I've only skimmed the patch, but I'm unclear what benefit this custom layer provides that standard java security providers and factories do not already provide?

          [...] it allows introducing additional methods in the future without the need to enumerate all of them in UserGroupInformation.AuthenticationMethod.

          I already plan to abolish this, perhaps with the RPCv9 sasl changes.

          Show
          Daryn Sharp added a comment - I've only skimmed the patch, but I'm unclear what benefit this custom layer provides that standard java security providers and factories do not already provide? [...] it allows introducing additional methods in the future without the need to enumerate all of them in UserGroupInformation.AuthenticationMethod. I already plan to abolish this, perhaps with the RPCv9 sasl changes.
          Hide
          Benoy Antony added a comment -

          The SaslClient and Sasl server implementations accept parameters including Callbackhandlers. These parameters could be independent of Hadoop or the Sasl Implementation. The custom layer allows the user to specify these parameters.

          I was studying the related SASL jiras. With those changes, the mechanism of plugging in AuthenticationMethods is going to change. I'll contribute to those jiras.

          Show
          Benoy Antony added a comment - The SaslClient and Sasl server implementations accept parameters including Callbackhandlers. These parameters could be independent of Hadoop or the Sasl Implementation. The custom layer allows the user to specify these parameters. I was studying the related SASL jiras. With those changes, the mechanism of plugging in AuthenticationMethods is going to change. I'll contribute to those jiras.

            People

            • Assignee:
              Benoy Antony
              Reporter:
              Benoy Antony
            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:

                Development