hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-8758) Support for pluggable token implementations
Date Mon, 17 Sep 2012 13:56:08 GMT

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

Daryn Sharp commented on HADOOP-8758:

bq. Kerberos and tokens are coupled in the sense that today delegation tokens can only be
fetched if authenticated over Kerberos

HADOOP-8779 and its subtasks will allow tokens to be used with basic auth.  It's the first
step in the more generalized support for tokens with any auth.  There are a lot of conditionals
that assume secure auth means kerberos which can be addressed by this jira.

bq.  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.

I'm not sure a new mechanism per auth method is needed since DIGEST-MD5 is a generic auth
mechanism supported by other auth services.  For instance, LDAP directly supports the DIGEST-MD5
mechanism and it's a common practice to provide the backend auth via PAM.  LoginContext is
java's PAM-like equivalent, so it seems a natural for the SASL callbacks to delegate to a
LoginContext which can be configured to validate the credentials via the secret manager (tokens)
or other auth modules such as LDAP.  These additional auth methods would be supported by a
simple change to the LoginContext config and no other code changes!
> 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

View raw message