[jira] [Commented] (HADOOP-9392) Token based authentication and Single Sign On

["Kai Zheng (JIRA)" <ji...@apache.org>]

    [ 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