[
https://issues.apache.org/jira/browse/HADOOP-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638917#comment-13638917
]
Kai Zheng commented on HADOOP-9392:
-----------------------------------
Hi Thomas,
Thanks for your notice. I’ve related HADOOP-9479 and also HADOOP-9296 to this
issue. Yes the provided custom authentication provider in HADOOP-9479’s patch
can be helpful for us to implement token based authentication. Meanwhile, the
work plus Shibboleth JAAS module you mentioned have nothing to do with the
common token in our context. That’s what this JIRA focuses on, abstracting
common token from all kinds of authentication mechanisms based on identity
products and backends and using the token in Hadoop. You’re right common token
holds identity attributes in bound from external authentication system and will
be used in Hadoop for authorization and audit stuffs, thus we do have to deal
with more tokens since we already have delegation token, job token and etc.
Regarding how they coexist and what’s the difference, may I quote a previous
email I responded, as below.
“As you can see in the initial security design doc, the tokens you mentioned
came out as work around in situations where Kerberos isn’t suitable due to
performance, deployment and etc.
Such tokens are different from out common authentication token targeted in
Rhino project in following aspects.
1. The tokens are more shared secrets for internal usage among Hadoop services,
while common token is for authenticating to external identity system;
2. The tokens are of various formats and very application specific, while
common token desires to be unified of both basic identity attributes and
extended attributes;
3. Common token can be used for single sign on among Hadoop services, while the
tokens are not intended in this consideration;
4. Common token with its built-in attributes can be used for authorization in
Hadoop services, but the tokens are only applicable for the targeted and
special scenarios.
At the same time, they don’t conflict.
1. When external authentication is passed with common token responded, relevant
Hadoop services/clients can request the tokens for example job token for
internal usage;
2. Maybe we can borrow some “pattern” or “model” from existing tokens for our
common token design.
Anyhow, common token is not for replacing the existing tokens, they can coexist
serving different purposes.
“
For you to start with and our possible POC of this concept if you’d like, I
think you could:
1. Have a simple common token;
2. Choose one authentication and JAAS module as you may already got for
Shibboleth;
3. Wrap the authentication result and identity attributes into the common token;
4. Authenticate the client common token to server via the mechanism proposed
and provided in HADOOP-9479;
5. Try to use the common token for authorization.
Please let me if this is doable for you.
Thanks.
> 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
> Fix For: 3.0.0
>
>
> 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
