hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alejandro Abdelnur (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-8758) Support for pluggable token implementations
Date Tue, 04 Sep 2012 21:36:07 GMT

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

Alejandro Abdelnur commented on HADOOP-8758:

A recurrent pattern I've seen in secure deployments is that in many cases they don't want
to expose Kerberos outside of the cluster/gateway machines. Specially on the browsers. Due
to internal IT rules, they don't want to kerberize enduser computers (many times laptops).
Given this, I think we should consider decoupling cluster/inter-services authentication (based
on Kerberos) from user facing authentication (based on something more palatable like LDAP
or AD).

Regarding the current token mechanism, there are several classes and sub-classses for different
components, I wonder why we need all of them instead using a single implementation.

Finally, on Eric's comment, I think most services already provide proxyuser support for propagating
caller credentials. JT/NN/Oozie/HttpFS do. May not the ideal mechanism but it works fine.
> 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