[
https://issues.apache.org/jira/browse/HADOOP-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656115#comment-13656115
]
Larry McCay commented on HADOOP-9392:
-------------------------------------
Thank you for taking the time to read the overview, Kai. You've pointed out a
couple things that I will have to make more clear in a revision to that
document. One being that you interpreted the service access token as purely
being used as an authenticator. This is not actually the case. One of the
primary purposes of having a secondary token for accessing the service is
carrying the arbitrary attributes used for fine-grained access control
decisions. This is why the service access token expires frequently. Since the
acquisition of these attributes is done at service access token request time,
those attributes that are interrogated by policy are able to be as fresh as
possible without having to re-authenticate. Cluster access tokens, on the other
hand, are longer lived and are used to represent the authenticated user and the
event of authentication itself. This way, service access tokens can be provided
to clients that have been authenticated with specific types of authentication
event requirements - like a strength level of the authentication performed.
Perhaps, a deployment would prefer one IDP over another for accessing a
particular service. Like the Authorization Codes in OAuth, it can be persisted
and utilized by many types of applications - upon expiry it needs to be
refreshed or the user needs to be re-authenticated. By indicating specific
scopes for the cluster access token, it may be given to third-parties to use on
the user's behalf with a constrained ability to acquire service access tokens
to only those services indicated by the list of scopes. We see the separation
of concerns between the two tokens as important to eliminate unnecessary
re-authentication, limit the amount of damage that a compromised token can
enable and ensure freshness of authorization related attributes.
Your thoughts of HSSO across clusters is very much in line with what we
envision as our use of HSSO within the perimeter security story that is
targeted by Knox. I tried to leave the multi-cluster usecases out of this
overview as to not muddy the waters with the perimeter story. It seems that
maybe it leaked into the document a bit - I guess the IDP Discovery protocol
leaks it. Anyway, I am curious whether you see a usecase for multiple clusters
without it being a perimeter based deployment. I think that I will save the
discussion of the multi-cluser deployments for another thread though.
We definitely envision and plan on a service registry component to HSSO which
aligns well with your thoughts about layering HSSO over TAS - we see the
authenticating and service registry components as going hand in hand.
We are in the process of making arrangements for a security get together at
Hadoop Summit next month. I hope that you will be able to attend. This will be
a great opportunity to get together and talk about this rationalization,
layering and multi-cluster deployment usecases. We should try and identify
aspects of this work for the agenda.
> 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
