[
https://issues.apache.org/jira/browse/HADOOP-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13675264#comment-13675264
]
Sanjay Radia commented on HADOOP-9392:
--------------------------------------
Thanks for the Jira and the slides on what you are proposing.
{quote}
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)
{quote}
I am puzzled by the above statement. Hadoop has delegation tokens and a trust
model. For the largest part we use delegation tokens (e.g. MR job client gets
HDFS delegation tokens etc) so that the job can run as the user that submitted
the job. Further in some cases we use trusted proxies like Ozzie (but this can
be any trusted service, not just Oozie), to access system services as specific
users. The delegation tokens and the trusted proxies are two independent
mechanisms. So I feel the statements in the quoted block are not correct or
perhaps you are using the term "delegation" in a different sense. Details of
the Hadoop delegation tokens are in the following very detailed paper on Hadoop
security (see
http://hortonworks.com/wp-content/uploads/2011/10/security-design_withCover-1.pdf).
You also state "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)" Note the at internal Hadoop
tokens are separate from the Kerberos tokens - indeed they are nicely decoupled
- the problem, IMHO, is not the decoupling but other issues. Another issue is
the authentication implementation which has a burnt-in notion of supporting
UGI, Keberos or the delegation tokens for authentication. As Daryn pointed out
this implementation needs to change so that the authentication mechanism is
pluggable. This jira, I believe, is proposing much much more than making this
implementation pluggable.
Don't get me wrong, I am not criticizing the Jira but merely trying to
understand some of the statements in the description and the slides you have
posted. I do agree that we need to allow other forms of authentication besides
Kerberos/ActiveDir. I also agree that attributes like group membership should
have been part of the Hadoop delegation tokens to avoid back calls which are
not feasible in cloud environments. Do you have a more detailed design besides
the slides that you have uploaded to this jira? I would like to get the next
level of details. Your comments in this jira do give some more details but it
would be good to put them in a design document. Further, I suspect you are
trying to replace the Hadoop delegation tokens - i don't disagree with that but
would like to understand the why and how from your perspective.
Would this be an accurate description of this Jira: "Single sign on for
non-kerberos environments using tokens". Hadoop does support "single sign on"
for kerberos/activeDir environments; of course that is not good enough since
many customers do not have Kerberos/ActiveDir.
> 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
