[
https://issues.apache.org/jira/browse/HADOOP-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668373#comment-13668373
]
Daryn Sharp commented on HADOOP-9392:
-------------------------------------
This is great information but a bit overwhelming. I have so many questions,
I'm not sure where to start. Bear with me, because I'm sure I missed some
details.
The client generates its own id token? While this can be verified with PKI,
what prevents another service from stealing the id token for its own use?
I'm concerned about the client embedding its groups into the id token. The
client is always untrustworthy, so it's really the server that should determine
and enforce groups.
I'm unclear how existing auth, like kerberos, fits into this model. Does the
client do kerberos auth with its TGT to the authn server before generating its
id token? If so, what prevents the client from skipping that step? A kerberos
callback is mentioned. Does this mean the client is passing its TGT to another
service?
How does a server compare its id token with the client's id token? What's
embedded in the client id token that allows this to occur?
What does it mean that an authentication module is JAAS based but not
necessarily the same?
Additional cluster-specific conf settings should be avoided if possible.
Config management for multi-cluster envs is already burdensome. Ideally
we/hadoop should be moving towards a client being able to access with multiple
clusters with a single config.
Has a meetup time at the summit been organized? I've scanned my mountain of
email but didn't see one.
> 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
