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

Daryn Sharp commented on HADOOP-9296:
-------------------------------------

I really don't think a new authentication method is needed for this "feature", 
nor should the client have do any special logic.  There's nothing special that 
warrants contortions on the client to do simple gssapi/kerberos.

The root cause is the client "guesses" the principal for a remote NN based on 
the principal of its default NN.  This causes a number of problems which also 
manifests in your cross-realm trust environment.  In HADOOP-9421 I've suggested 
the NN should provide the service of the token it wants, as well as the service 
principal.  Why not leverage that to solve your no cross-realm trust problem?  
Ie. Have the NN return the principal in the user's realm.  In this scenario, no 
client changes are required, and no special authentication method is required.
                
> Authenticating users from different realm without a trust relationship
> ----------------------------------------------------------------------
>
>                 Key: HADOOP-9296
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9296
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: security
>            Reporter: Benoy Antony
>            Assignee: Benoy Antony
>         Attachments: HADOOP-9296-1.1.patch, multirealm.pdf
>
>
> Hadoop Masters (JobTracker and NameNode) and slaves (Data Node and 
> TaskTracker) are part of the Hadoop domain, controlled by Hadoop Active 
> Directory. 
> The users belong to the CORP domain, controlled by the CORP Active Directory. 
> In the absence of a one way trust from HADOOP DOMAIN to CORP DOMAIN, how will 
> Hadoop Servers (JobTracker, NameNode) authenticate  CORP users ?
> The solution and implementation details are in the attachement

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

Reply via email to