[jira] [Commented] (HADOOP-8758) Support for pluggable token implementations

["Kan Zhang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HADOOP-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446789#comment-13446789 ] 

Kan Zhang commented on HADOOP-8758:
-----------------------------------

Upon initial look at the code, it seems the changes required to the RPC layer is small and low risk. The main changes seem to be passing in a list of SecretManagers, instead of just one, to the constructor of SaslDigestCallbackHandler. And the callback handler's private method getPassorword() needs to consult all SecretManagers in turn and return the first password found. No changes to the flow of connection setup. Changes are localized to how we return the required token password when given a token identifier.

                
> Support for pluggable token implementations
> -------------------------------------------
>
>                 Key: HADOOP-8758
>                 URL: https://issues.apache.org/jira/browse/HADOOP-8758
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: ipc, security
>            Reporter: Kan Zhang
>            Assignee: Kan Zhang
>
> Variants of the delegation token mechanism have been employed by different Hadoop services (NN, JT, RM, etc) to re-authenticate a previously Kerberos-authenticated client. While existing delegation token mechanism compliments Kerberos well, it doesn't necessarily have to be coupled with Kerberos. In principle, delegation tokens can be coupled with any authentication mechanism that bootstraps security. In particular, it can be coupled with other token implementations that use the same DIGEST-MD5 auth method. For example, a token can be pre-generated in an out-of-band manner and configured as a shared secret key between NN and JT to allow JT to make initial authentication to NN. This simple example doesn't deal with token renewal etc, but it helps to illustrate the point that if we can support multiple pluggable token implementations, it opens up the possibility for different users to plug in the token implementation of their choice to bootstrap security. Such token based mechanism has advantages over Kerberos in that 1) it doesn't require Kerberos infrastructure, 2) it leverages existing SASL DIGEST-MD5 auth method and doesn't require adding a new RPC auth method.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira