Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Sun, 2 Sep 2012 07:14:07 +1100 (NCT)
From: "Kan Zhang (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <763853378.27462.1346530447565.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=
46795#comment-13446795 ]=20

Kan Zhang commented on HADOOP-8758:
-----------------------------------

Existing SecretManager is always included in the list and is consulted firs=
t. Others can be made configurable by the users. This way there is no chang=
e to existing behavior.
               =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