[
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
