hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yu Gao (JIRA)" <>
Subject [jira] [Commented] (HIVE-3719) Improve HiveServer to support username/password authentication
Date Sat, 17 Nov 2012 03:31:12 GMT


Yu Gao commented on HIVE-3719:

First introduce several new configuration properties:
  <description>Turn on hive authentication</description>
  <description>If you want to turn on SSL connection between hive jdbc client and hive
server, set it to true. false by default</description>
  <value>authentication class name</value>
  <description>Class for authenticating user credentials</description>

Overall design:
HiveServer Thrift API will remain unchanged, and all changes needed are related to underlying
thrift socket connection. Basically use SASL PLAIN mechanism to send username and password
from client to server for authentication. In addition, SSL option is also provided to encrypt
transmitted data.

The change is backward compatible, so the new JDBC driver can talk to both old and improved
HiveServer, and the old JDBC driver can as well talk to new HiveServer as long as authentication
is turned off on the server.

1. Hive JDBC driver
If property is set to “password”, SASL transport with plain
mechanism is used, so if there's no username/password provided throw exception directly on
client side; if the property is not set or the value is not password, continue with original
socket connection without SASL. Thrift SSL can be enabled by property defaulted
to false, so if it's turned on, all transmitted data will be encrypted.

Client can easily set these two properties through connection arguments, the same way it passes
in "user" and "password" property.

2. Hive server (standalone)
HiveServer checks property, and it will use SASL server transport
with plain mechanism if the value is “password” (either with SSL or non-SSL per

Once get the username and password, the server will do authentication by using the class set
in property We provide an authentication interface
and user-provided class for authentication must inherit from it. 

For authorization, introduce a ugi-assuming processor for HiveServer, similar to the existing
one for MetaStore thrift server, which uses an ugi-doAs in its process method, and thus all
client calls from the authenticated connection will be within this ugi context and hive authorization
will be performed against this user.

3. Hive server (embedded)
For embedded hive jdbc server, there're no socket connections involved and thrift server handler
is directly called, so in this case authentication will be performed before handler is called
and ugi context can be set through ThreadLocal variable, and of course the way to obtain ugi
for authorization in this case will be adjusted accordingly.

> Improve HiveServer to support username/password authentication
> --------------------------------------------------------------
>                 Key: HIVE-3719
>                 URL:
>             Project: Hive
>          Issue Type: Improvement
>          Components: Authentication, JDBC
>    Affects Versions: 0.9.0
>            Reporter: Yu Gao
>              Labels: security
> The current HiveServer implementation (call it HiveServer version 1 to distinguish it
from HIveServer2 that is under development currently) does not have any authentication mechanism
against connecting clients, which means anyone can access it, e.g. through Hive JDBC driver,
without any security control. The user and password property are simply ignored by Hive JDBC
driver and never get to HiveServer1.
> It would be good to introduce authentication infrastructure to HiveServer 1, and improve
JDBC driver implementation as well to support this, so that together with the existing authorization
infrastructure, for applications that want to access HiveServer1 via JDBC driver, connections
and operations are under security control.
> Although there's HiveServer2 that has been under implementation for a while, this improvement
for HiveServer1 is very necessary to fill the big security hole, and would benefit applications
a lot that are using HiveServer1.

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:

View raw message