[
https://issues.apache.org/jira/browse/HADOOP-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633923#comment-13633923
]
Kai Zheng commented on HADOOP-9392:
-----------------------------------
Hi Thomas,
We discussed about this via email in a long thread, and now it’s great you are
about to do something implementing the common token. To get more involved in
community, I’d like to cite your questions from your email regarding how to
implement and answer them in this JIRA. See below. Thanks.
Question 1: “If I'm not wrong, the authentication method is set at
initialization by looking at "core-site.xml". During authentication, Hadoop has
to check the UGI to determine which mode is used, and then choose the path
accordingly (if authentication=.....).
To decouple Hadoop internal use from external authentication, we should remove
all these paths and choose only one solution (based on common token). It sounds
rather complex depending on the context..”
Answer: You’re right understanding the current Hadoop authentication. There’re
already a few of authentication methods and one of them can be configured and
then used globally. To go in our way and also keep backward compatible, we can
keep the existing methods, at the same time add a new authentication method for
common token authentication as an advanced one like Kerberos. To implement the
new method, we can have token provider service which
issues/validates/renews/revokes token for users utilizing pluggable
authentication module based on external authentication provider as the backend
we’d like to target. To keep it simple, the token provider can be implemented
and provided as just a library, in future we can promote it to be standalone
service.
Question 2: “Do you have any suggestion about how the "common token provider"
should be implemented?
I have picture a mechanism like Shibboleth (for my intercloud scenario), the
user is redirected to its authentication system to provide credentials
(username,password) and if the authentication succeeds, the common token is
provided.”
“Do you have any idea which form the user attributes should be implemented in
the common token?”
Answer: Based on my answer to question 1, here it comes to how to implement the
above mentioned token provider service. Providing the token provider service
interfaces are defined for Hadoop, to implement it we can consider existing
SSO/federation standards/solutions such as SAML or Shibboleth. For the common
token we may consider SAML token as its format.
Question 3: “After reading the discussions of the related Jiras, I also have
another question: By using our framework, user will be forced to use common
token even if he uses "simple authentication". Is it problematic?”
Answer: As answered to question 1, we keep the existing methods when we provide
this advanced option, and Hadoop customer won’t be forced to use which one.
> Token based authentication and Single Sign On
> ---------------------------------------------
>
> Key: HADOOP-9392
> URL: https://issues.apache.org/jira/browse/HADOOP-9392
> Project: Hadoop Common
> Issue Type: New Feature
> Components: security
> Reporter: Kai Zheng
> Fix For: 3.0.0
>
>
> This is an umbrella entry for one of project Rhino’s topic, for details of
> project Rhino, please refer to
> https://github.com/intel-hadoop/project-rhino/. The major goal for this entry
> as described in project Rhino was
>
> “Core, HDFS, ZooKeeper, and HBase currently support Kerberos authentication
> at the RPC layer, via SASL. However this does not provide valuable attributes
> such as group membership, classification level, organizational identity, or
> support for user defined attributes. Hadoop components must interrogate
> external resources for discovering these attributes and at scale this is
> problematic. There is also no consistent delegation model. HDFS has a simple
> delegation capability, and only Oozie can take limited advantage of it. We
> will implement a common token based authentication framework to decouple
> internal user and service authentication from external mechanisms used to
> support it (like Kerberos)”
>
> We’d like to start our work from Hadoop-Common and try to provide common
> facilities by extending existing authentication framework which support:
> 1. Pluggable token provider interface
> 2. Pluggable token verification protocol and interface
> 3. Security mechanism to distribute secrets in cluster nodes
> 4. Delegation model of user authentication
--
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
