[
https://issues.apache.org/jira/browse/HADOOP-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13658295#comment-13658295
]
Larry McCay commented on HADOOP-9392:
-------------------------------------
Hi Kai - my previous response hadn't really intended to compare the designs as
much as correct something that - based on your interpretation - must have been
understated in my client interaction overview on HADOOP-9533. Any decent design
would strive to address these same goals - I didn't mean to imply that your's
doesn't. Ultimately, we just want to make sure that we are covering all
relevant goals and usecases in our converged approach. I mentioned the OAuth
similarity as an analogue with an existing token based protocol for addressing
restricted capabilities of a given token. The same type of analogue can be
drawn between HADOOP-9533 and Kerberos. The cluster access token is similar to
the TGT while the service access token is much like a service ticket. Service
user scenarios are covered in an upcoming overview document for In-cluster
trust establishment and service:service authentication that will be published
on HADOOP-9533.
I do agree that keeping the number of tokens that are required for a
client/user-agent to keep track of is a good idea from the complexity and
developer experience perspectives. We will however have to strike a balance
between simplicity and a design that meets all of our goals.
Enumerating the properties of each design at this point will provide little
value. Instead, I propose that we articulate all of the relevant goals and
usecases of the required design. Including attack vectors and scenarios that we
must address with the ultimate design. Deployment scenarios of the Hadoop
cluster will be important to consider as well. We will also need to take into
account the capabilities of all the clients in the ecosystem for supporting it.
With some of this groundwork done, we can get together at the Summit with an
agenda item to reconcile those goals and usecases into a converged design.
Discussions around the deployment scenarios will help drive how any layering
will be done between Knox at the perimeter and HSSO and TAS inside the cluster.
I do have some questions about the authorization approach as well. We can keep
that as a separate discussion - probably better had on the HADOOP-9466 Jira?
I will look into having a bridge available for the get together.
> 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
