[
https://issues.apache.org/jira/browse/HADOOP-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13676939#comment-13676939
]
Kai Zheng commented on HADOOP-9392:
-----------------------------------
Daryn- Sorry for late response, your comments are great and very welcome.
Identity token is issued by TAS when client authentication is passed, and TAS
is trusted by Hadoop services. Token needs to authenticate to service and
pluggable client token authenticator/validator is allowed. The authenticator
can be configured per service according to service specific security policies
to reject invalid tokens. As discussed with Kyle we are considering an Access
Token with audience restriction annotations. Sure token should be protected
avoiding to be leaked and used by other client/user and we’ll discuss about
this separately.
As above mentioned, TAS along with its issued tokens is trusted by Hadoop
services/servers. The token with its attributes is encrypted and signed. As to
which attributes should be contained in identity token, we can discuss about it
separately. However, I don’t think group is something special, if we employ
fine-grained access control against other attributes like role, they should be
important too. Identity attributes can come from various Attribute Authorities
in the enterprise outside of the Hadoop cluster. Most importantly we desire to
abstract all of this from Hadoop into our proposed frameworks to simplify the
configuration, deployment, and administration of large or multiple Hadoop
clusters.
Based on TokenAuth framework, we’re about to support Kerberos mechanism by
KerberosTokenAuthnModule as mentioned in the doc, and the module can be used to
authenticate TAS client via Kerberos. In this case TAS client needs to pass
Kerberos authentication first via kinit or keytab, then authenticates to the
authentication module as accessing a service via service ticket, and finally
gets an identity token. The mentioned callback for principal instead of ticket
might not be used.
Client identity token wraps identity attributes from user, and service identity
token wraps service attributes and security policies specific to the service.
As default implementation, token realm trusting based authenticator is used to
validate client token using service’s token. As discussed with Kyle, custom
token validator can be plugined per service to employ advanced validation
mechanisms. Note we are considering Access Token and when it’s used this
validating of client token against service token might not be applied and the
token validator can be simplified.
Totally agree with that we/Hadoop should simplify the security configuration
and deployment for Hadoop. In TokenAuth deployment, Hadoop only needs to be
aware of TAS, without bothering to understand and configure concrete
authentication providers. I agree we support multiple clusters, so let’s see
how we can provide best support so that TAS can be layered for that. Regarding
concrete configuration properties as simple as possible I would like to discuss
then separately.
> 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
