[
https://issues.apache.org/jira/browse/HADOOP-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451452#comment-13451452
]
Kan Zhang commented on HADOOP-8758:
-----------------------------------
Daryn, I agree we should support multiple external authentication methods and
we should make external auth methods configurable by the user. By "external", I
meant the auth methods that are allowed to fetch delegation tokens. These
external auth methods are typically used when clients make initial connections
to a Hadoop cluster. After that, delegation tokens may be fetched and future
connections may be set up using an internal auth method (with those fetched
delegation tokens). Today, in terms of RPC, we have one external auth method
(Kerberos) and one internal auth method (DIGEST-MD5). And they are tightly
coupled. By breaking that tight coupling, we can make external auth methods
(SIMPLE auth can be one, LDAP can be another) configurable. I should point out
SecretManagers are not authorization methods, nor are they authentication
methods. They are just different ways to set up credentials (shared keys) to be
used with DIGEST-MD5 auth method. We could consider supporting multiple
internal auth methods, but currently I don't see a need. The purpose of this
JIRA is to allow DIGEST-MD5 to be used also as an external auth method, with a
different way to set up credentials (tokens are pre-generated and
pre-configured). Did I answer your question?
> 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
