hadoop-common-issues mailing list archives

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

    [ 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

Mime
View raw message