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

Josh Elser resolved ACCUMULO-4665.
----------------------------------
    Resolution: Fixed

> Must use the "real" User for RPCs when Kerberos is enabled.
> -----------------------------------------------------------
>
>                 Key: ACCUMULO-4665
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4665
>             Project: Accumulo
>          Issue Type: Bug
>          Components: rpc
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Critical
>             Fix For: 1.7.4, 1.8.2, 2.0.0
>
>          Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> In the normal Kerberos authentication case, a User(GroupInformation) has a 
> username and a set of credentials for that user. This is the typical case 
> because a user is accessing Accumulo from their local machine or a machine 
> where they can obtain a Kerberos ticket from the KDC.
> However, there are certain situations where another service is accessing 
> Accumul on behalf of the end-user. We do not want to share our ticket 
> (password) with the service for security reasons, but would still like this 
> service to be able to access Accumulo on our behalf. We refer to this as 
> "proxy-user authentication" or "impersonation".
> The Accumulo Proxy is a common scenario for this: an end-user {{josh}} with 
> Kerberos credentials authenticates to the Accumulo proxy (who is running as 
> {{proxyserver}}). The Proxy then authenticates to Accumulo as {{josh}} even 
> though its credentials are for {{proxyserver}}. We refer to this as {{josh}} 
> is proxied on {{proxyserver}}.
> Down in ThriftUtil, we pull the current UGI and use that to automatically 
> wrap any Thrift RPCs in a doAs() call to ensure that Thrift can access the 
> Kerberos credentials to perform the SASL authentication handshake. The 
> problem is that when we have a proxy-user scenario, the Thrift RPC doesn't 
> have access to the credentials and fails.
> The fix is rather simple: make sure that we always use the "real" user that 
> has kerberos credentials, not any "proxy" user.
> I came across this problem re-testing some integration of the Hive-Accumulo 
> integration with Hiveserver2 (which plays the same role as the Accumulo Proxy 
> as described above).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to