hadoop-common-issues mailing list archives

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

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

Daryn Sharp commented on HADOOP-9392:

bq.  What we meant by inconsistent is the ecosystem coverage for delegation, it can’t be
done everywhere, Hadoop delegation today is HDFS centric.

That is not true.  Delegation tokens are embedded at the RPC layer, so it's a capability that
any service using the common RPC may use.  YARN extensively uses the same delegation token
framework, and MR uses it for the history server.

bq. Yes you’re right we imply other issues, and you might agree that the implementation
of UGI should change so authentication mechanisms can plug in more easily. In my understanding,
Daryn might be working on those issues related to allow plugin authentication mechanisms but
in the current way.

While the current design does have flaws, it can be adapted and improved in an incremental
fashion.  In a nutshell, after my changes: the client and server will be able to negotiate
the authentication method, and use the mechanism specified by the server for that method.
 The client will essentially start to "just do what it's told" by the server.  Eventually
the UGI should be able to trigger an on-demand JAAS login for a given auth type, versus today's
automatic login at instantiation.   There's little reason why the UGI's auth type mapping
cannot become dynamic perhaps via a service loader.  I think this meshes with your goals.

My high level goals are to provide better extensibility with minimal disruptive behavior.

The original driver of my work is to allow security & tokens to be enabled w/o kerberos.
 This requires pluggable auth methods, in my case, adding support for SASL PLAIN as a substitute
for SIMPLE.  Providing security sans kerberos will allow developers and/or pre-commit to catch
token related bugs so people like me don't have to chase so many of them. :)  You can then
plug in your own auth types, such as ldap, new tokens, etc.

Another driver is adding SASL auth method negotiation to compliment support for multiple auth
methods, and extending this negotiation to enable new capabilities.  Ex. heterogenous security
clusters/services, supporting multi-interface servers which indirectly allows HA to use IP
failover, etc.

Given all the discussions involving more radical changes to the security framework, I'm very
keen to providing the modularity required to implement these systems, but _in a manner that
will not destabilize the existing security implementation_, else Yahoo's 2.x deployments may
be delayed.
> 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

View raw message