[
https://issues.apache.org/jira/browse/HADOOP-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13447751#comment-13447751
]
Owen O'Malley commented on HADOOP-8758:
---------------------------------------
This is reasonable, although it isn't pluggable token implementations as much
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.)
I really wish we had a better SASL shared secret implementation than one that
depends on MD5, whose strength is already pretty questionable. Clearly that 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 is
already pluggable using servlet filters. Further, we've already done
proprietary and spnego security filters, so I suspect that it is flexible
enough for most purposes. It doesn't require any sasl, rpc, or client changes
and doesn't break backwards compatibility. Would that work for your use case?
> 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
