[
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
