Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Wed, 5 Sep 2012 02:28:08 +1100 (NCT)
From: "Owen O'Malley (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <801020808.33060.1346772488510.JavaMail.jiratomcat@arcas>
In-Reply-To: <433406900.27436.1346528588314.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (HADOOP-8758) Support for pluggable token
 implementations
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HADOOP-8758?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D134=
47751#comment-13447751 ]=20

Owen O'Malley commented on HADOOP-8758:
---------------------------------------

This is reasonable, although it isn't pluggable token implementations as mu=
ch as adding new authentication mechanisms. (In other words, you shouldn't =
change the token mechanisms like the secret manager, but add an alternative=
 to Kerberos and delegation tokens.)=20

I really wish we had a better SASL shared secret implementation than one th=
at depends on MD5, whose strength is already pretty questionable. Clearly t=
hat is a related, but different issue.

I think a fruitful direction would be to figure out how to authenticate the=
 HTTP connection that fetches delegation tokens.  The HTTP authentication i=
s already pluggable using servlet filters. Further, we've already done prop=
rietary and spnego security filters, so I suspect that it is flexible enoug=
h for most purposes. It doesn't require any sasl, rpc, or client changes an=
d doesn't break backwards compatibility. Would that work for your use case?
               =20
> 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 differen=
t Hadoop services (NN, JT, RM, etc) to re-authenticate a previously Kerbero=
s-authenticated client. While existing delegation token mechanism complimen=
ts Kerberos well, it doesn't necessarily have to be coupled with Kerberos. =
In principle, delegation tokens can be coupled with any authentication mech=
anism that bootstraps security. In particular, it can be coupled with other=
 token implementations that use the same DIGEST-MD5 auth method. For exampl=
e, 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 authentic=
ation to NN. This simple example doesn't deal with token renewal etc, but i=
t helps to illustrate the point that if we can support multiple pluggable t=
oken implementations, it opens up the possibility for different users to pl=
ug in the token implementation of their choice to bootstrap security. Such =
token based mechanism has advantages over Kerberos in that 1) it doesn't re=
quire Kerberos infrastructure, 2) it leverages existing SASL DIGEST-MD5 aut=
h 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 administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira