[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=13672714#comment-13672714 ] 

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

Kyle – Thanks for your questions.

1) The client token needs to authenticate to a service when it’s used to access the service. We consider a token realm trust based authenticator for the simple case and initial implementation. A user can implement and configure more advanced or enterprise specific client token authenticators on a per service basis. (This is as the doc states: “Other mechanisms other than trust method may be enforced for token realm to authenticate other token realms in future”.) However, enforcement of complicated client token authentication polices might introduce significant performance overhead on handshaking with the service.  We might have a update about this and consider other approaches when going on with our authorization work. Initially the TokenAuth design focuses on pluggable authentication for multiple domains and single sign on using a single token. Meanwhile elsewhere we are also working on a Unified Authorization framework. That authorization framework is where we would introduce similar constructs like the OAuth Access Token to enforce fine-grained access control, authorization trust management, and transference. That access token can be issued by another entity, some Authorization Server other than TAS, targeting one service, maybe a set of resources. Very possibly, the resulting access token in the authorization framework can be aligned with the Service Access Token. In this way the service authenticating client token can be simplified since relevant policies per the service have already been enforced prior to the service request when issuing the access token.
2) The Identity Token is a bearer token. It is signed and encrypted when issued by the TAS, and decrypted and verified when used by the service. The transport of the token is secured, either between TAS and client, or client and service.
3) About AD/LDAP: We simply group Active Directory and LDAP as examples of a family of related identity stores. Both speak LDAP.  When designing connectors to LDAP and AD as identity back ends for TokenAuth and the TAS, we intend to look at them as separate design targets on account of differing capabilities. Particularly, considering Active Directory is dominantly deployed in enterprises and also evolving in cloud platform as an IdP solution,  it could make sense to integrate AD in more advanced mode via an authentication module in TAS. Such module can be used in web contexts, where web browser can be redirected by HadoopTokenAuthnFilter to the AD IdP to authenticate when accessing Hadoop service via web interface. When being back HadoopTokenAuthnHandler will represent the result IdP token to the authentication module and TAS to exchange an identity token, and then the result identity token will be used to request corresponding resources.

                
> 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
>
>
> 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