Mailing-List: contact dev-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Date: Fri, 3 Jan 2014 23:48:51 +0000 (UTC)
From: "Shivaraju Gowda (JIRA)" <jira@apache.org>
To: hive-dev@hadoop.apache.org
Message-ID: <JIRA.12665668.1377592366771.41308.1388792930995@arcas>
In-Reply-To: <JIRA.12665668.1377592366771@arcas>
References: <JIRA.12665668.1377592366771@arcas>
Subject: [jira] [Commented] (HIVE-5155) Support secure proxy user access to
 HiveServer2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Shivaraju Gowda commented on HIVE-5155:
---------------------------------------

It is important to note that the middle ware server does not have access to Principal's credentials. All it has is a javax.security.auth.Subject("Subject") from the end-user(Principal) and can do a Subject.doAS() to connect to HiveServer2. In Proposal 2, the middle ware server is expected to have access to Hadoop-level super-user's credentials(by doing "kinit") or it has the Subject from a Hadoop-level super-user which has been passed on to it. In the code I have attached above, I am trying to show that any end-user's Subject can be effectively used to connect to HiveServer2 using Subject.doAs() in the middle ware server. This  will allow multi-user kerberos access through the middleware server without additional requirements of proxy access. I might have overlooked or be unaware of some limitations of such an approach, so I am soliciting feedback to check that.

> Support secure proxy user access to HiveServer2
> -----------------------------------------------
>
>                 Key: HIVE-5155
>                 URL: https://issues.apache.org/jira/browse/HIVE-5155
>             Project: Hive
>          Issue Type: Improvement
>          Components: Authentication, HiveServer2, JDBC
>    Affects Versions: 0.12.0
>            Reporter: Prasad Mujumdar
>            Assignee: Prasad Mujumdar
>         Attachments: HIVE-5155-1-nothrift.patch, HIVE-5155-noThrift.2.patch, HIVE-5155-noThrift.4.patch, HIVE-5155-noThrift.5.patch, HIVE-5155-noThrift.6.patch, HIVE-5155.1.patch, HIVE-5155.2.patch, HIVE-5155.3.patch, ProxyAuth.java, ProxyAuth.out, TestKERBEROS_Hive_JDBC.java
>
>
> The HiveServer2 can authenticate a client using via Kerberos and impersonate the connecting user with underlying secure hadoop. This becomes a gateway for a remote client to access secure hadoop cluster. Now this works fine for when the client obtains Kerberos ticket and directly connects to HiveServer2. There's another big use case for middleware tools where the end user wants to access Hive via another server. For example Oozie action or Hue submitting queries or a BI tool server accessing to HiveServer2. In these cases, the third party server doesn't have end user's Kerberos credentials and hence it can't submit queries to HiveServer2 on behalf of the end user.
> This ticket is for enabling proxy access to HiveServer2 for third party tools on behalf of end users. There are two parts of the solution proposed in this ticket:
> 1) Delegation token based connection for Oozie (OOZIE-1457)
> This is the common mechanism for Hadoop ecosystem components. Hive Remote Metastore and HCatalog already support this. This is suitable for tool like Oozie that submits the MR jobs as actions on behalf of its client. Oozie already uses similar mechanism for Metastore/HCatalog access.
> 2) Direct proxy access for privileged hadoop users
> The delegation token implementation can be a challenge for non-hadoop (especially non-java) components. This second part enables a privileged user to directly specify an alternate session user during the connection. If the connecting user has hadoop level privilege to impersonate the requested userid, then HiveServer2 will run the session as that requested user. For example, user Hue is allowed to impersonate user Bob (via core-site.xml proxy user configuration). Then user Hue can connect to HiveServer2 and specify Bob as session user via a session property. HiveServer2 will verify Hue's proxy user privilege and then impersonate user Bob instead of Hue. This will enable any third party tool to impersonate alternate userid without having to implement delegation token connection.


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)