[
https://issues.apache.org/jira/browse/HDFS-4056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478451#comment-13478451
]
Kan Zhang commented on HDFS-4056:
---------------------------------
What combinations of initial and subsequent auth modes are we going to support?
Will a client end up being able to authenticate to a server in 2 or more ways?
In such cases, what takes precedence? Maybe the answer depends on what type of
client it is, for example, a job client should always use SIMPLE to
authenticate to NN since it needs to fetch tokens. Whereas a task should always
use token if DIGEST-MD5 is specified for subsequent auth. Given certain initial
auth method, is there a need to support more than one subsequent auth modes
simultaneously (i think not)? Bottom line is the server should always be able
to figure out by itself whether a connection is an initial connection or a
subsequent one, based on the auth method (and type of credentials) used, since
it needs to decide on whether tokens can be issued for that connection. These
are just some questions in my mind. It would be best to have a document
describing what things are legal and supported, and what should happen in
various scenarios. Without making those things clear, I think it's premature to
start on changes on the server side. For example, if we are going to support
SIMPLE + SIMPLE then we shouldn't always start NN's SecretManager.
> Always start the NN's SecretManager
> -----------------------------------
>
> Key: HDFS-4056
> URL: https://issues.apache.org/jira/browse/HDFS-4056
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: name-node
> Affects Versions: 0.23.0, 2.0.0-alpha, 3.0.0
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Attachments: HDFS-4056.patch
>
>
> To support the ability to use tokens regardless of whether kerberos is
> enabled, the NN's secret manager should always be started.
--
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
