[ https://issues.apache.org/jira/browse/HADOOP-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13655883#comment-13655883 ]
Kai Zheng commented on HADOOP-9392: ----------------------------------- I agree we need to rationalize to avoid overlap and more importantly simplify configuration and deployment issues for the ecosystem. Let’s compare TokenAuth with HSSO, and see what is missing that HSSO would need to add. HSSO provides a Cluster Access Token, which is similar to the Identity Token in TokenAuth. HSSO also provides a Service Access Token to authenticate targeted services and bear additional attributes for authorization. In TokenAuth, the Identity Token (from now on just “access token”) is issued to the client when authentication to the Token Authentication Service (TAS) for the user domain is successful. Then the same token is used to authenticate to the target service. TokenAuth’s access token also carries various attributes set at authentication time, and supports arbitrary additional attributes. In HADOOP-9466 we have designed a unified authorization framework based on this singular access token. In my view, the access token is for authorization of concrete resources. HSSO’s “Service Access Token” is in contrast an authenticator. It lacks features for fine grained authorization. I think that is why you are wondering to what degree you can match up the OAuth spec to this. The HSSO server registers and maintains authentication providers, and TokenAuth’s TAS does the same work. However, TAS not only covers authentication mechanism for RPC and command line environments, it also covers IDPs for web services. The two parts of TokenAuth’s TAS is a complete solution. What is interesting about HSSO is that it targets the multiple Hadoop cluster use case and lets clients dynamically discover the right authentication provider for the given target cluster. TokenAuth targets mainly the singular cluster use case but allows multiple organizations to use it. I think HSSO and TokenAuth can complement each other in a seamless way if HSSO can focus on the multiple cluster use case layered on top of TokenAuth authentication within the cluster, as follows: 1. The HSSO server is the central registry of Token Authentication Services (TASes) of one or more Hadoop clusters, and it accepts client requests to be forwarded to the appropriate TAS for authentication in the target cluster; 2. Enhance the TAS allowing it to identify an HSSO server by configuring the HSSO registry endpoint; 3. The TAS registers itself to the HSSO with the cluster name as the key; 4. Hadoop clients first contact the HSSO to locate the appropriate TAS by cluster name and domain, then connect to the TAS for authentication. The concrete authentication provider(s) that will be used to authenticate the client will be determined by the TAS by default. Of course if HSSO needs to support dynamically discovering IDP(s) for clients this would be ok since it won’t impact the TAS much. Note that the discovery should be local to the TAS. Please let me know your thoughts. 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 > > > 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