[ https://issues.apache.org/jira/browse/HADOOP-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13658225#comment-13658225 ]
Kai Zheng commented on HADOOP-9392: ----------------------------------- Larry - You use an extra Service Access Token to “eliminate unnecessary re-authentication, limit the amount of damage that a compromised token can enable and ensure freshness of authorization related attributes”, however TokenAuth addresses these concerns without requiring two types of tokens. The Identity Token is cached at the client and will be reused for subsequent requests to avoid re-authentication. Tokens in the cache are expired at a configurable interval, typically a few hours instead of days. When the client requests access to a service, the token provided by the client is authenticated to the TAS configured for the service and at that time the TAS validates the token, verifies the associated identity is valid and also if the principal is still allowed to access the service. Furthermore identity attributes should be of the same freshness with the identity itself. As with other attributes that can be used for authorization, they should be collected and evaluated on a per request basis, and they often involve resources other than coarse-grained service level access considerations. Such attributes are often retrieved during authorization enforcement from Attribute Authority(AA), for example in XACML context it should be in PDP. We cover fine-grained authorization in the Unified Authorization Framework (HADOOP-9466) based on TokenAuth. If there’s a relationship between a Service Access Token and an OAuth Access Token, I’m not sure it’s in the right way. In OAuth, the Access Token is issued by Authorization Server in an Authorization Grant from the Resource Owner. Do you intend for the HSSO service to take on the role of an OAuth Resource Owner? If yes then how will you handle service users? Please consider if we can avoid introducing additional tokens like the Service Access Token. Probably we can address your design concerns in other ways. Also, do we need two similar tokens for authentication and SSO in Hadoop (the Identity Token in TokenAuth, and the Cluster Access Token in HSSO)? I believe Hadoop only needs one. Cleanup of redundant constructs emitted from the two partially overlapping proposals here I would think is the first step toward aligning these efforts. We should consider a deployment model where we build HSSO layered on TAS. Sounds like a good plan for us to meet at the Hadoop Summit. I will try but not sure if I can make it. Others from the team who are also working on this will be there and participate in the discussion. If there is a bridge, I will try to join the bridge. Thanks for setting this up. > 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