[
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
