[ 
https://issues.apache.org/jira/browse/HADOOP-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kai Zheng updated HADOOP-10959:
-------------------------------

    Attachment: KerbToken-v2.pdf

The design doc. Your comments are welcome. Thanks.

> 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 soon. Below is the brief introduction.
> We proposed to add token-preauth mechanism similar to PKINIT and OTP for 
> Kerberos based on the Pre-Authentication framework, which allows users to 
> authenticate to KDC using a JWT token instead of password. KDC authenticates 
> the JWT token and issues TGT as it would trust the token authority/issuer via 
> PKI mechanism. The proposal was submitted to Kerberos and IETF Kitten WG and 
> they’re interested. Currently we’re collaborating with MIT team to work on 
> the draft and standardize the mechanism. We also did a POC which implemented 
> the token-preauth mechanism as a MIT Kerberos plugin. The plugin can be 
> separately packaged as a Linux .so module and deployed additionally for 
> existing installations. MIT also wish we could contribute the codes and make 
> it available in their future releases. Before that we can make the plugin 
> binary and source codes available to the community for experimental usage and 
> review.
> So ideally token-preauth plugin can be deployed to a MIT Kerberos 
> installation, the end users can authenticate to 3rd party JWT token 
> authorities and get tokens, and then use the tokens to acquire Kerberos TGT 
> from KDC. Based on that, we implemented the token authentication for Hadoop, 
> with only a few of central modifications into the code base, as we don’t have 
> to add another Authentication Method and the solution leverages the existing 
> Kerberos support.
> We added KrbTokenLoginModule that extends the Krb5LoginModule and adds to 
> support logging in using a token or token cache. The new module is compatible 
> with Krb5LoginModule in configuration and functionality, thus can be used 
> safely.
> We also added KerberosTokenAuthenticationHandler to support Hadoop web 
> interfaces. It extends KerberosAuthenticationHandler and adds to support 
> token authentication and perform the SPNEGO negotiation purely in server side 
> in the new handler. Again the new handler is compatible with 
> KerberosAuthenticationHandler and can be used safely.
> Token is used to exchange Kerberos ticket and ticket goes to Hadoop services 
> as normally does. In addition to that, to employ the token attributes to 
> enforce fine-grained authorization or whatever, a token derivation is 
> encapsulated into ticket as Authorization data when KDC issues the ticket 
> with the token. Then in service (Hadoop services) side, token can be queried 
> and extracted from service ticket. We made this happen in both GSSAPI and 
> SASL contexts as the both are used in Hadoop.
> As we can see or think of, the main concern for this solution may be that it 
> requires to deploy additional plugin for existing Kerberos installations, and 
> involves necessary identity accounts sync from identity management systems to 
> Kerberos KDC. Most importantly, it requires Kerberos deployment as its 
> prerequisite setup. We’re also discussing with MIT team about how to simplify 
> Kerberos deployment especially for Hadoop large clusters and alleviate the 
> overhead to employ PKINIT/token-preauth mechanisms like identity sync. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to