[
https://issues.apache.org/jira/browse/HADOOP-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13457026#comment-13457026
]
Daryn Sharp commented on HADOOP-8758:
-------------------------------------
bq. Kerberos and tokens are coupled in the sense that today delegation tokens
can only be fetched if authenticated over Kerberos
HADOOP-8779 and its subtasks will allow tokens to be used with basic auth.
It's the first step in the more generalized support for tokens with any auth.
There are a lot of conditionals that assume secure auth means kerberos which
can be addressed by this jira.
bq. Secret managers were created to serve SASL DIGEST-MD5 callbacks. They are
credential managers for DIGEST-MD5 mechanism. If you are talking about adding
auth methods other than DIGEST-MD5, the right place is adding a SASL mechanism,
not overloading DIGEST-MD5.
I'm not sure a new mechanism per auth method is needed since DIGEST-MD5 is a
generic auth mechanism supported by other auth services. For instance, LDAP
directly supports the DIGEST-MD5 mechanism and it's a common practice to
provide the backend auth via PAM. LoginContext is java's PAM-like equivalent,
so it seems a natural for the SASL callbacks to delegate to a LoginContext
which can be configured to validate the credentials via the secret manager
(tokens) or other auth modules such as LDAP. These additional auth methods
would be supported by a simple change to the LoginContext config and no other
code changes!
> 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
