hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tianyou Li (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9392) Token based authentication and Single Sign On
Date Fri, 12 Jul 2013 13:05:49 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706912#comment-13706912
] 

Tianyou Li commented on HADOOP-9392:
------------------------------------

Hi Brian,
 
Please allow me to clarify your concerns first and then switch to your comments about how
this feature(s) proceeding.
 
> Regarding a client passing credentials to TAS: It seems that you are saying that a client
would not pass credentials to TAS in all scenarios.This is not reflected in the diagram.
 
In the scenarios mentioned when IdP does not have the capability of generating trusted token,
TAS can be used as agent to collect credentials and then pass the credentials to IdP, which
exactly reflected by the flow shows in page 3. Maybe we should add another diagram to address
the scenarios of exchanging a token by supplying credentials to IdP directly. Or we can use
the term ‘identity data store’ for LDAP, DB etc to distinguish with ‘IdP’ from the
term ‘identity backend’. 
 
> I also am not sure what you mean by "TAS should be trusted by client for authentication"
 
That means when client is initiating authentication process with TAS, the TAS should prove
itself to the client. This can be done via SSL/TLS server certificate, and enable SSL/TLS
can also secure the credentials transmission in the following authentication process. 
 
> Trusting with credentials violates basic security principles, which I would not see as
an improvement in Hadoop security.
 
We only do ‘Trusting with credentials’ when necessary. With our experience of supporting
customer with identity data store such like LDAP, DB etc, the way we presents in page 3 is
very common and can also be observed in PingFederate, SecureAuth etc. In addition, the credentials
can be collected by TAS but that does not mean TAS will and need to persistent credentials,
or pass the credentials on the wire if digest or other mechanism is available.
 
 
 
Now back to the comments of how this feature(s) proceeding:
 
> I do think that breaking things down into sub-tasks is a good idea
 
I agree with that, and we will update the jira(s) in near future.
 
> One work item that fits into your design is that of adding token support to RPC endpoints.
This is a work item that would add value for customers right away while still allowing flexibility
in the rest of the design. This is something we would like to begin work on now (after consulting
Daryn Sharp, since I understand he's been doing some work in this area).
 
We agree that support for RPC endpoints provides immediate value add for customers. We are
working on the patch related to RPC level authN, based on some good work from Daryn. Hopefully
we can publish that patch real soon and start a more “narrowly-scoped discussion” with
patch for the sub-tasks which use 9392 as umbrella. 
 
Regards.

                
> 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, token-based-authn-plus-sso-v2.0.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