[
https://issues.apache.org/jira/browse/HADOOP-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14097027#comment-14097027
]
Daryn Sharp commented on HADOOP-10959:
--------------------------------------
bq. token-preauth conforms to all these and won't undermine Kerberos.
Undermine as in bypassing a password/keytab means kerberos is no longer the
source of truth for passwords. Will jwt support revoking a kvno? After a
referral is issued in a cross-realm setup, will the KDC continue to trust the
origin KDC or will it revalidate the jwt kvno?
bq. [...] So a MIT KDC can trust an AD for a set of users and a token authority
for another set of users at the same time in a deployment, and the
token-preauth plugin is only needed by the MIT KDC.
How will the jwt be injected in the TGT/TGS? If the user kdc (usually AD)
doesn't have the jwt plug-in, how does the jwt get injected into tickets after
the referral to the (possibly MIT) cluster kdc?
bq. I think delegation token works well internally to bypass some Kerberos
constraint.
{quote}bq. are they using the JWT tokens to obtain a TGT/TGS in the tasks? I
think the latter?{quote}
bq. Great idea. Should this go so far I don't know.
No, it's a terrible idea. :) I was just seeking clarification. Tens of
thousands of tasks per cluster bombarding kdcs isn't scalable. Delegation
tokens were in part designed to avoid excessive kdc load and latency, and to
shield the job from service/network interruptions to the kdc.
bq. Yes token-preauth (with the new AD-TOKEN) is to be standardized. In this
extension, JWT token MAY(not REQUIRE) contain groups and also other useful
attributes. If it does, then such attribute(s) can be extracted and employed
for authorization.
If delegation tokens continue to be used, this implies that groups will need to
propagate the groups from the jwt into the delegation token. I'm not certain
how I feel about the service not being its own source of authority for groups...
bq. think about how to prepare for the long time running service principals and
keytabs to be scheduled to run in dynamic containers?
Storm already does this. The level of security is arguable, but it routinely
pushes new forwardable TGTs to the topology.
> A Complement and Short Term Solution to TokenAuth Based on Kerberos
> Pre-Authentication Framework
> ------------------------------------------------------------------------------------------------
>
> Key: HADOOP-10959
> URL: https://issues.apache.org/jira/browse/HADOOP-10959
> Project: Hadoop Common
> Issue Type: New Feature
> Components: security
> Reporter: Kai Zheng
> Assignee: Kai Zheng
> Labels: Rhino
> Attachments: KerbToken-v2.pdf
>
>
> To implement and integrate pluggable authentication providers, enhance
> desirable single sign on for end users, and help enforce centralized access
> control on the platform, the community has widely discussed and concluded
> token based authentication could be the appropriate approach. TokenAuth
> (HADOOP-9392) was proposed and is under development to implement another
> Authentication Method in lieu with Simple and Kerberos. It is a big and long
> term effort to support TokenAuth across the entire ecosystem. We here propose
> a short term replacement based on Kerberos that can complement to TokenAuth.
> Our solution involves less codes changes with limited risk and the main
> development work has already been done in our POC. Users can use our solution
> as a short term solution to support token inside Hadoop.
> This effort and resultant solution will be fully described in the design
> document to be attached. And the brief introduction will be commented.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
