[ 
https://issues.apache.org/jira/browse/HADOOP-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14095693#comment-14095693
 ] 

Daryn Sharp commented on HADOOP-10959:
--------------------------------------

I digress, but I'm not sure why generating principals and keytabs seems to be 
viewed as a difficult activity.  Most if not nearly all large corporations 
already use kerberos in some form.  Here's a few initial thoughts/questions:

My impression it's a misnomer to call this a pre-auth extension?  It's not a 
hardening like the encrypted timestamp pre-auth, but instead is a complete 
substitute for a password/keytab.  Doesn't this completely undermine kerberos?

Will cross-realm authentication work?  Do all KDCs in the trust have to use the 
custom plugin?

I probably overlooked it, but how do tasks running in the cluster authenticate 
under the model?  Do they continue to use the existing delegation tokens 
obtained via JWT/TGT during job submission, or are they using the JWT tokens to 
obtain a TGT/TGS in the tasks?  I think the latter?

The doc says having the NN configured for user to group mappings is not ideal.  
Mention is made of an AD-TOKEN which I believe is a non-standard MS extension?  
Do you envision the JWT issuer containing the group mapping for all services?

bq. However, the pain to deploy keytabs for services can be alleviated by token 
support, still, another story.

I'm not sure how you remove the "pain" of copying a file.  For mutual auth, I 
would expect something like certificates or private keys or shared secret to be 
involved - which would be an equal but different "pain to deploy"?

> 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)

Reply via email to