[
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
