hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kai Zheng (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9392) Token based authentication and Single Sign On
Date Sun, 02 Jun 2013 23:24:21 GMT

    [ 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

Mime
View raw message