[
https://issues.apache.org/jira/browse/HADOOP-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13703588#comment-13703588
]
Brian Swan commented on HADOOP-9392:
------------------------------------
Thanks, Kai, for the updated design doc. I've spent some time reading it and
have a few comments/questions:
1. The new diagram (p. 3) that describes client/TAS/AS/IdP/Hadoop Services
interaction shows a client providing credentials to TAS, which then provides
the credentials to the IdP. From a security perspective, this seems like a bad
idea. It defeats the purpose of having an IdP in the first place. Is this an
oversight or by design?
2. I'm not sure I understand *why* AS is necessary. It seems to complicate the
design by adding an unnecessary authorization check - authorization can/should
happen at individual Hadoop services based on token attributes. I think you
have mentioned before that authorization (with AS in place) would happen at
both places (some level of authz at AS and finer grained authz at services).
Can you elaborate on what value that adds over doing authz at services only?
And, can you provide an example of what authz checks would happen at each
place? (Say I access NameNode. What authz checks are done at AS and what is
done at the service?)
3. I believe this has been mentioned before, but the scope of this document
makes it very difficult to move forward with contributing code. It would be
very helpful to understand how you envision breaking this down into work items
that the community can pick up (I think this is what the DISCUSS thread on
common-dev was attempting to do).
To further my last point, from my perspective, 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). However, it's not clear to me (based on comments in
the DISCUSS thread on common-dev) if you are already writing code for this. It
would be unfortunate to duplicate work here. If you have something concrete to
share, that would be great.
Thanks.
> 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
