hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kai Zheng (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9392) Token based authentication and Single Sign On
Date Thu, 06 Jun 2013 11:52:24 GMT

    [ 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

View raw message