[
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
