[
https://issues.apache.org/jira/browse/HADOOP-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456451#comment-13456451
]
Kan Zhang commented on HADOOP-8758:
-----------------------------------
bq. Kerberos and tokens are not coupled in any form. The secret managers know
nothing about the authentication method. Multiple auth methods, such as LDAP,
can currently be added with no change to the secret managers.
Kerberos and tokens are coupled in the sense that today delegation tokens can
only be fetched if authenticated over Kerberos. This JIRA is to break that
coupling such that connections authenticated over a special type of tokens
(depending on configuration) are also allowed to fetch delegation tokens.
bq. The blocking issue is that hadoop's SASL DIGEST-MD5 callbacks directly call
the token secret managers. What it should do is call into a LoginContext which
can be configured for multiple auth methods.
Secret managers were created to serve SASL DIGEST-MD5 callbacks. They are
credential managers for DIGEST-MD5 mechanism. If you are talking about adding
auth methods other than DIGEST-MD5, the right place is adding a SASL mechanism,
not overloading DIGEST-MD5.
> 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
