[ 
https://issues.apache.org/jira/browse/HADOOP-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718088#comment-13718088
 ] 

Kai Zheng commented on HADOOP-9392:
-----------------------------------

Thanks for your thoughts. Sorry for being late to reply this as we're busy with 
breaking down TokenAuth and working on our initial patch. HAS (Hadoop A* 
Server) is good and I like it. The 'A' of HAS could be explained as 
"Authentication", "Authorization", or "Auditing" or more of them, depending on 
HAS is provisioned with which role(s). In this way it's much flexible and 
better to evolve in future. In high level considerations, we may need 
centralized Authentication Server, centralized Authorization Server, or even 
centralized Auditing Server, and such servers would be great to be combined 
into one centralized server, or deployed separately regarding 
network/multi-tenancy concerns. Currently we're mainly focusing on 
"Authentication" and "Authorization" aspects, and the two roles can be 
provisioned into one server, or separate servers, and the server can be just 
unified and named as HAS.

In TokenAuth, we use Identity Token and Access Token in places where 
appropriate, and only mention token in contexts that the token can be clearly 
interpreted as either Identity Token or Access Token. If HAS is accepted, then 
we can use “HAS tokens” to mean Identity/Access Tokens in TokenAuth as you 
suggested. Considering Hadoop existing tokens such as delegation token/block 
token/job token and the like are widely used today we can continue to use 
“Hadoop tokens” to mean them.

Please let me know what's your further thought about this. Thanks.
                
> 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
>            Assignee: Kai Zheng
>             Fix For: 3.0.0
>
>         Attachments: token-based-authn-plus-sso.pdf, 
> token-based-authn-plus-sso-v2.0.pdf
>
>
> 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

Reply via email to