hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kan Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-8758) Support for pluggable token implementations
Date Sun, 23 Sep 2012 01:30:12 GMT

    [ 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

Mime
View raw message