[
https://issues.apache.org/jira/browse/HADOOP-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461308#comment-13461308
]
Kan Zhang commented on HADOOP-8758:
-----------------------------------
Daryn, as I explained before, this JIRA is to remove the requirement on
Kerberos as the only external auth method and allow for other auth methods like
SIMPLE and, in particular, DIGEST-MD5 itself to be used as external auth
methods. If you want to do the removing in HADOOP-8779 and enable SIMPLE auth
to be used as an alternative to Kerberos, that's fine. Once HADOOP-8779 is
done, this JIRA will be trivial.
You might have some misunderstanding of DIGEST-MD5 and how it's used in Hadoop
RPC. You can't delegate SASL DIGEST-MD5 callbacks to a LoginContext which
validates client credentials on LDAP, since in DIGEST-MD5, clients will not
send their credentials to server. DIGEST-MD5 is a challenge-response protocol.
Server needs to know client credentials (token passwords) to perform
authentication and hence the need for callbacks. Secret managers are there to
serve SASL DIGEST-MD5 callbacks.
> 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
