[
https://issues.apache.org/jira/browse/HIVE-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13499336#comment-13499336
]
Yu Gao commented on HIVE-3719:
------------------------------
First introduce several new configuration properties:
<property>
<name>hive.security.authentication</name>
<value>password</value>
<description>Turn on hive authentication</description>
</property>
<property>
<name>hive.security.ssl</name>
<value>true/false</value>
<description>If you want to turn on SSL connection between hive jdbc client
and hive server, set it to true. false by default</description>
</property>
<property>
<name>hive.security.password.verification.class</name>
<value>authentication class name</value>
<description>Class for authenticating user credentials</description>
</property>
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 hive.security.authentication 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 hive.security.ssl 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 hive.security.authentication, and it will use SASL
server transport with plain mechanism if the value is “password” (either with
SSL or non-SSL per hive.security.ssl).
Once get the username and password, the server will do authentication by using
the class set in property hive.security.password.verification.class. 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: https://issues.apache.org/jira/browse/HIVE-3719
> 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: http://www.atlassian.com/software/jira
