You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@drill.apache.org by br...@apache.org on 2017/03/16 02:20:59 UTC
[2/5] drill git commit: Reorganize content for securing drill updates
http://git-wip-us.apache.org/repos/asf/drill/blob/74e0fee7/_docs/configure-drill/076-configuring-user-impersonation-with-hive-authorization.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/076-configuring-user-impersonation-with-hive-authorization.md b/_docs/configure-drill/076-configuring-user-impersonation-with-hive-authorization.md
deleted file mode 100644
index bab9697..0000000
--- a/_docs/configure-drill/076-configuring-user-impersonation-with-hive-authorization.md
+++ /dev/null
@@ -1,268 +0,0 @@
----
-title: "Configuring User Impersonation with Hive Authorization"
-date: 2016-01-05
-parent: "Configure Drill"
----
-As of Drill 1.1, you can enable impersonation in Drill and configure authorization in Hive version 1.0 to authorize access to metadata in the Hive metastore repository and data in the Hive warehouse. Impersonation allows a service to act on behalf of a client while performing the action requested by the client. See [Configuring User Impersonation]({{site.baseurl}}/docs/configuring-user-impersonation).
-
-There are two types of Hive authorizations that you can configure to work with impersonation in Drill: SQL standard based and storage based authorization.
-
-## SQL Standard Based Authorization
-
-You can configure Hive SQL standard based authorization in Hive version 1.0 to work with impersonation in Drill 1.1. The SQL standard based authorization model can control which users have access to columns, rows, and views. Users with the appropriate permissions can issue the GRANT and REVOKE statements to manage privileges from Hive.
-
-For more information, see [SQL Standard Based Hive Authorization](https://cwiki.apache.org/confluence/display/HIVE/SQL+Standard+Based+Hive+Authorization).
-
-## Storage Based Authorization
-
-You can configure Hive storage based authorization in Hive version 1.0 to work with impersonation in Drill 1.1. Hive storage based authorization is a remote metastore server security feature that uses the underlying file system permissions to determine permissions on databases, tables, and partitions. The unit style read/write permissions or ACLs that a user or group has on directories in the file system determine access to data. Because the file system controls access at the directory and file level, storage based authorization cannot control access to data at the column or view level.
-
-You manage user and group privileges through permissions and ACLs in the distributed file system. You manage storage based authorization through the remote metastore server to authorize access to data and metadata.
-
-DDL statements that manage permissions, such as GRANT and REVOKE, do not affect permissions in the storage based authorization model.
-
-For more information, see [Storage Based Authorization in the Metastore Server](https://cwiki.apache.org/confluence/display/Hive/Storage+Based+Authorization+in+the+Metastore+Server).
-
-## Configuration
-
-Once you determine the Hive authorization model that you want to implement, enable impersonation in Drill, update the `hive-site.xml` file with the relevant parameters for the authorization type, and modify the Hive storage plugin configuration in Drill with the relevant properties for the authorization type.
-
-### Prerequisites
-
-* Hive 1.0 installed
-* Drill 1.1 or later installed
-* Hive remote metastore repository configured
-
-## Step 1: Enabling Drill Impersonation
-
-Modify `<DRILL_HOME>/conf/drill-override.conf` on each Drill node to include the required properties, set the [maximum number of chained user hops]({{site.baseurl}}/docs/configuring-user-impersonation/#chained-impersonation), and restart the Drillbit process.
-
-1. Add the following properties to the `drill.exec` block in `drill-override.conf`:
-
- drill.exec: {
- cluster-id: "<drill_cluster_name>",
- zk.connect: "<hostname>:<port>,<hostname>:<port>,<hostname>:<port>"
- impersonation: {
- enabled: true,
- max_chained_user_hops: 3
- }
- }
-
-2. Issue the following command to restart the Drillbit process on each Drill node:
-`<DRILLINSTALL_HOME>/bin/drillbit.sh restart`
-
-## Step 2: Updating hive-site.xml
-
-Update hive-site.xml with the parameters specific to the type of authorization that you are configuring and then restart Hive.
-
-### Storage Based Authorization
-
-Add the following required authorization parameters in hive-site.xml to configure storage based authentication:
-
-**hive.metastore.pre.event.listeners**
-**Description:** Enables metastore security.
-**Value:** org.apache.hadoop.hive.ql.security.authorization.AuthorizationPreEventListener
-
-**hive.security.metastore.authorization.manager**
-**Description:** Tells Hive which metastore-side authorization provider to use. The default setting uses DefaultHiveMetastoreAuthorizationProvider, which implements the standard Hive grant/revoke model. To use an HDFS permission-based model (recommended) for authorization, use StorageBasedAuthorizationProvider.
-**Value:** org.apache.hadoop.hive.ql.security.authorization.StorageBasedAuthorizationProvider
-
-**hive.security.metastore.authenticator.manager**
-**Description:** The authenticator manager class name in the metastore for authentication.
-**Value:** org.apache.hadoop.hive.ql.security.HadoopDefaultMetastoreAuthenticator
-
-**hive.security.metastore.authorization.auth.reads**
-**Description:** When enabled, Hive metastore authorization checks for read access.
-**Value:** true
-
-**hive.metastore.execute.setugi**
-**Description:** When enabled, this property causes the metastore to execute DFS operations using the client's reported user and group permissions. This property must be set on both the client and server sides. If the cient and server settings differ, the client setting is ignored.
-**Value:** true
-
-**hive.server2.enable.doAs**
-**Description:** Tells HiveServer2 to execute Hive operations as the user submitting the query. Must be set to true for the storage based model.
-**Value:** true
-
-
-
-### Example of hive-site.xml configuration with the required properties for storage based authorization
-
- <configuration>
- <property>
- <name>hive.metastore.uris</name>
- <value>thrift://10.10.100.120:9083</value>
- </property>
-
- <property>
- <name>javax.jdo.option.ConnectionURL</name>
- <value>jdbc:derby:;databaseName=/opt/hive/hive-1.0/bin/metastore_db;create=true</value>
- </property>
-
- <property>
- <name>javax.jdo.option.ConnectionDriverName</name>
- <value>org.apache.derby.jdbc.EmbeddedDriver</value>
- </property>
-
- <property>
- <name>hive.metastore.pre.event.listeners</name>
- <value>org.apache.hadoop.hive.ql.security.authorization.AuthorizationPreEventListener</value>
- </property>
-
- <property>
- <name>hive.security.metastore.authenticator.manager</name>
- <value>org.apache.hadoop.hive.ql.security.HadoopDefaultMetastoreAuthenticator</value>
- </property>
-
- <property>
- <name>hive.security.metastore.authorization.manager</name>
- <value>org.apache.hadoop.hive.ql.security.authorization.StorageBasedAuthorizationProvider</value>
- </property>
-
- <property>
- <name>hive.security.metastore.authorization.auth.reads</name>
- <value>true</value>
- </property>
-
- <property>
- <name>hive.metastore.execute.setugi</name>
- <value>true</value>
- </property>
-
- <property>
- <name>hive.server2.enable.doAs</name>
- <value>true</value>
- </property>
- </configuration>
-
-
-## SQL Standard Based Authorization
-
-Add the following required authorization parameters in hive-site.xml to configure SQL standard based authentication:
-
-**hive.security.authorization.enabled**
-**Description:** Enables Hive security authorization.
-**Value:** true
-
-**hive.security.authenticator.manager**
-**Description:** Class that implements HiveAuthenticationProvider to provide the client\u2019s username and groups.
-**Value:** org.apache.hadoop.hive.ql.security.SessionStateUserAuthenticator
-
-**hive.security.authorization.manager**
-**Description:** The Hive client authorization manager class name.
-**Value:** org.apache.hadoop.hive.ql.security.authorization.plugin.sqlstd.SQLStdHiveAuthorizerFactory
-
-**hive.server2.enable.doAs**
-**Description:** Tells HiveServer2 to execute Hive operations as the user submitting the query. Must be set to false for the storage based model.
-**Value:** false
-
-**hive.users.in.admin.role**
-**Description:** A comma separated list of users which gets added to the ADMIN role when the metastore starts up. You can add more uses at any time. Note that a user who belongs to the admin role needs to run the "set role" command before getting the privileges of the admin role, as this role is not in the current roles by default.
-**Value:** Set to the list of comma-separated users who need to be added to the admin role.
-
-**hive.metastore.execute.setugi**
-**Description:** In unsecure mode, setting this property to true causes the metastore to execute DFS operations using the client's reported user and group permissions. Note: This property must be set on both the client and server sides. This is a best effort property. If the client is set to true and the server is set to false, the client setting is ignored.
-**Value:** false
-
-
-### Example of hive-site.xml configuration with the required properties for SQL standard based authorization
-
- <configuration>
- <property>
- <name>hive.metastore.uris</name>
- <value>thrift://10.10.100.120:9083</value>
- </property>
-
- <property>
- <name>javax.jdo.option.ConnectionURL</name>
- <value>jdbc:derby:;databaseName=/opt/hive/hive-1.0/bin/metastore_db;create=true</value>
- </property>
-
- <property>
- <name>javax.jdo.option.ConnectionDriverName</name>
- <value>org.apache.derby.jdbc.EmbeddedDriver</value>
- </property>
-
- <property>
- <name>hive.security.authorization.enabled</name>
- <value>true</value>
- </property>
-
- <property>
- <name>hive.security.authenticator.manager</name>
- <value>org.apache.hadoop.hive.ql.security.SessionStateUserAuthenticator</value>
- </property>
-
- <property>
- <name>hive.security.authorization.manager</name>
- <value>org.apache.hadoop.hive.ql.security.authorization.plugin.sqlstd.SQLStdHiveAuthorizerFactory</value>
- </property>
-
- <property>
- <name>hive.server2.enable.doAs</name>
- <value>false</value>
- </property>
-
- <property>
- <name>hive.users.in.admin.role</name>
- <value>user</value>
- </property>
-
- <property>
- <name>hive.metastore.execute.setugi</name>
- <value>false</value>
- </property>
- </configuration>
-
-## Step 3: Modifying the Hive Storage Plugin
-
-Modify the Hive storage plugin configuration in the Drill Web Console to include specific authorization settings. The Drillbit that you use to access the Web Console must be running.
-
-Complete the following steps to modify the Hive storage plugin:
-
-1. Navigate to `http://<drillbit_hostname>:8047`, and select the **Storage tab**.
-2. Click **Update** next to "hive."
-3. In the configuration window, add the configuration properties for the authorization type.
-
- * For storage based authorization, add the following properties:
-
- {
- type:"hive",
- enabled: true,
- configProps : {
- "hive.metastore.uris" : "thrift://<metastore_host>:<port>",
- "fs.default.name" : "hdfs://<host>:<port>/",
- "hive.metastore.sasl.enabled" : "false",
- "hive.server2.enable.doAs" : "true",
- "hive.metastore.execute.setugi" : "true"
- }
- }
- * For SQL standard based authorization, add the following properties:
-
- {
- type:"hive",
- enabled: true,
- configProps : {
- "hive.metastore.uris" : "thrift://<metastore_host>:9083",
- "fs.default.name" : "hdfs://<host>:<port>/",
- "hive.security.authorization.enabled" : "true",
- "hive.security.authenticator.manager" : "org.apache.hadoop.hive.ql.security.SessionStateUserAuthenticator",
- "hive.security.authorization.manager" : "org.apache.hadoop.hive.ql.security.authorization.plugin.sqlstd.SQLStdHiveAuthorizerFactory",
- "hive.metastore.sasl.enabled" : "false",
- "hive.server2.enable.doAs" : "false",
- "hive.metastore.execute.setugi" : "false"
- }
- }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
http://git-wip-us.apache.org/repos/asf/drill/blob/74e0fee7/_docs/configure-drill/078-configuring-web-ui-and-rest-api-security.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/078-configuring-web-ui-and-rest-api-security.md b/_docs/configure-drill/078-configuring-web-ui-and-rest-api-security.md
deleted file mode 100644
index a4fe0d0..0000000
--- a/_docs/configure-drill/078-configuring-web-ui-and-rest-api-security.md
+++ /dev/null
@@ -1,111 +0,0 @@
----
-title: "Configuring Web Console and REST API Security"
-date: 2016-02-08 21:57:12 UTC
-parent: "Configure Drill"
----
-Drill 1.5 extends [Drill user authentication]({{site.baseurl}}/docs/configuring-user-authentication/) to the Web Console and underlying REST API. As administrator, you can control the extent of access to the Web Console and REST API client applications. For example,
-you can limit the access of certain users to Web Console functionality, such as viewing the in-progress or completed queries of other users. You can limit users from viewing other users' query profiles, who can cancel queries of other users, and other functionality.
-
-With Web Console security in place, users who do not have administrator privileges need to use the SHOW SCHEMAS command instead of the Web Console for storage plugin configuration information.
-
-## HTTPS Support
-Drill 1.2 uses code-level support for transport layer security (TLS) to secure the Web Console and REST API. By default, the Web Console and REST API support the HTTP protocol. You set the following start-up option to TRUE to enable HTTPS support:
-
-`drill.exec.http.ssl_enabled`
-
-By default this start-up option is set to FALSE.
-
-Drill generates a self-signed certificate that works with SSL for HTTPS access to the Web Console. Because Drill uses a self-signed certificate, you see a warning in the browser when you go to `https://<node IP address>:8047`. The Chrome browser, for example, requires you to click `Advanced`, and then `Proceed to <address> (unsafe)`. If you have a signed certificate by an authority, you can set up a custom SSL to avoid this warning. You can set up SSL to specify the keystore or truststore, or both, for your organization, as described in the next section.
-
-## Setting Up a Custom SSL Configuration
-
-As cluster administrator, you can set the following SSL configuration parameters in the `conf/drill-override.conf` file, as described in the [Java product documentation](http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html/#Customization):
-
-* javax.net.ssl.keyStore
- Path to the application's certificate and private key in the Java keystore file.
-* javax.net.ssl.keyStorePassword
- Password for accessing the private key from the keystore file.
-* javax.net.ssl.trustStore
- Path to the trusted CA certificates in a keystore file.
-* javax.net.ssl.trustStorePassword
- Password for accessing the trusted keystore file.
-
-## Prerequisites for Web Console and REST API Security
-
-You need to perform the following configuration tasks using Web Console and REST API security.
-
-* Configure [user authentication]({{site.baseurl}}/docs/configuring-user-authentication/)
-* Set up Web Console administrators
- Optionally, you can set up Web Console administrator-user groups to facilitate management of multiple Web Console administrators.
-
-## Setting up Web Console Administrators and Administrator-User Groups
-
-Configure the following system options using the [ALTER SYSTEM]({{site.baseurl}}/docs/alter-system/) command:
-
-* security.admin.users
- Set the value of this option to a comma-separated list of user names who you want to give administrator privileges, such as changing system options.
-* security.admin.user_groups
- Set the value of this option to a comma-separated list of administrator groups.
-
-Any user who is a member of any group listed in security.admin.user.groups is a Drill cluster administrator. Any user for whom you have configured Drill user authentication, but not set up as a Drill cluster administrator, has only user privileges to access the Web Console and REST API client applications.
-
-## Web Console and REST API Privileges
-
-The following table and subsections describe the privilege levels for accessing the REST API methods and corresponding Web Console functions:
-
-* Administrator (ADMIN)
-* User (USER)
-* Administrator and User (ALL)
-
-| Resource Method | Path | Request Type | Output Type | Functionality | Privilege Level |
-|--------------------------|------------------------------|--------------|------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------|
-| getStats | / | GET | text/html | Returns Drillbit stats in a table in HTML format. | ALL |
-| getStatsJSON | /stats.json | GET | application/json | Returns Drillbit stats such as ports and max direct memory in json format. | ALL |
-| getStatus | /status | GET | text/html | Returns Running! | ALL |
-| getSystemOptionsJSON | /options.json | GET | application/json | Returns a list of options. Each option consists of name-value-type-kind (for example: (boot system datatype). | ALL |
-| getSystemOptions | /options | GET | text/html | Returns an HTML table where each row is a form containing the option details that allows option values to be modified. | ALL |
-| updateSystemOption | /option/{optionName} | POST | text/html | Updates the options and calls getSystemOptions. So again an option list is displayed. | ADMIN |
-| getStoragePluginsJSON | /storage.json | GET | application/json | Returns a list of storage plugin wrappers each containing name-config (instance of StoragePluginConfig) and enabled. | ADMIN |
-| getStoragePlugins | /storage | GET | text/html | Returns an HTML page with two sections: The first section contains a table of rows that are forms containing the plugin button for the update page and a button to disable the plugin. The second section is the same except the button enables the plugin. | ADMIN |
-| getStoragePluginJSON | /storage/{name}.json | GET | application/json | Returns a plugin config wrapper for the requested web page. | ADMIN |
-| getStoragePlugin | /storage/{name} | GET | text/html | Returns an HTML page that has an editable text box for configuration changes and buttons for creating/updating/deleting. Each button makes calls that regenerate the page. | ADMIN |
-| enablePlugin | /storage/{name}/enable/{val} | GET | application/json | Updates the storage plugin configuration status. Returns success or failure. | ADMIN |
-| deletePluginJSON | /storage/{name}.json | DELETE | application/json | Deletes the storage plugin. Returns success or failure. | ADMIN |
-| deletePlugin | /storage/{name}/delete | GET | application/json | Same as deletePluginJSON but a GET instead of a DELETE request. | ADMIN |
-| createOrUpdatePluginJSON | /storage/{name}.json | POST | application/json | Creates or updates the storage plugin configuration. Returns success or failure. Expects JSON input. | ADMIN |
-| createOrUpdatePlugin | /storage/{name} | POST | application/json | Same as createOrUpdatePluginJSON expects JSON or FORM input. | ADMIN |
-| getProfilesJSON | /profiles.json | GET | application/json | Returns currently running and completed profiles from PStore. For each profile a queryId, startTime, foremanAddress, query, user, and state is returned. Each list (running and completed) is organized in reverse chronological order. | [ADMIN, USER]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security/#get-/profiles.json) |
-| getProfiles | /profiles | GET | text/html | Generates an HTML page from the data returned by getProfilesJSON with a hyperlink to a detailed query page, | [ADMIN, USER]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security/#get-/profiles) |
-| getProfileJSON | /profiles/{queryid}.json | GET | application/json | Returns the entire profile in JSON. | [ADMIN, USER]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security/#get-/profiles/{queryid}.json) |
-| getProfile | /profiles/{queryid} | GET | text/html | Returns a complicated profile page. | [ADMIN, USER]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security/#get-/profiles/{queryid}) |
-| cancelQuery | /profiles/cancel/{queryid} | GET | text/html | Cancels the given query and sends a message. | [ADMIN, USER]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security/#get-/profiles/cancel/{queryid}) |
-| getQuery | /query | GET | text/html | Gets the query input page. | ALL |
-| submitQueryJSON | /query.json | POST | application/json | Submits a query and waits until it is completed and then returns the results as one big JSON object. | ALL |
-| submitQuery | /query | POST | text/html | Returns results from submitQueryJSON populated in a HTML table. | ALL |
-| getMetrics | /metrics | GET | text/html | Returns a page that fetches metric info from resource, status, and metrics. | ALL |
-| getThreads | /threads | GET | text/html | Returns a page that fetches metric information from resource, status, and threads. | ALL |
-
-### GET /profiles.json
-
-* ADMIN - gets all profiles on the system.
-* USER - only the profiles of the queries the user has launched.
-
-### GET /profiles
-
-* ADMIN - gets all profiles on the system.
-* USER - only the profiles of the queries the user has launched.
-
-### GET /profiles/{queryid}.json
-
-* ADMIN - return the profile.
-* USER - if the query is launched the by the requesting user return it. Otherwise, return an error saying no such profile exists.
-
-### GET /profiles/{queryid}
-
-* ADMIN - return the profile.
-* USER - if the query is launched the by the requesting user return it. Otherwise, return an error saying no such profile exists
-
-### GET /profiles/cancel/{queryid}
-
-* ADMIN - can cancel the query.
-* USER - cancel the query only if the query is launched by the user requesting the cancellation.
http://git-wip-us.apache.org/repos/asf/drill/blob/74e0fee7/_docs/configure-drill/securing-drill/010-securing-drill-introduction.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/010-securing-drill-introduction.md b/_docs/configure-drill/securing-drill/010-securing-drill-introduction.md
index b070c0a..9f6e504 100644
--- a/_docs/configure-drill/securing-drill/010-securing-drill-introduction.md
+++ b/_docs/configure-drill/securing-drill/010-securing-drill-introduction.md
@@ -1,29 +1,29 @@
---
title: "Securing Drill Introduction"
-date: 2017-03-15 00:30:47 UTC
+date: 2017-03-16 01:22:49 UTC
parent: "Securing Drill"
---
-Before connecting to a data source, you can configure Drill security features and [secure communication pathways]({{site.baseurl}}/docs/secure-drill/secure-communication-paths/) to a secure Drill cluster. Security features include:
-
-- **Authentication** - Drill supports user authentication to secure clusters with:
- - Kerberos.
- See [Kerberos Authentication]({{site.baseurl}}/docs/securing-drill/configuring-kerberos-authentication/).
- - Username and password (with the Plain mechanism or a Custom Authenticator). See:
- - [Plain Authentication]({{site.baseurl}}/docs/configuring-plain-authentication/)
- - [Creating Custom Authenticators]({{site.baseurl}}/docs/custom-authentication)
- - Digest
-- **Authorization** - Drill supports restricting an authenticated user's capabilities.
- See [Configuring User Impersonation with Hive Authorization]({{site.baseurl}}/docs/configuring-user-impersonation-with-hive-authorization/).
-- **Impersonation** - Drill executes queries on behalf of a client while performing the action requested by the client.
- See:
- - [Configuring User Impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/)
- - [Configuring Inbound Impersonation]({{site.baseurl}}/docs/configuring-inbound-impersonation/)
- - [Configuring User Impersonation with Hive Authorization]({{site.baseurl}}/docs/configuring-user-impersonation-with-hive-authorization/)
-- **Encryption** - Drill does not support encryption as of Drill 1.10.
-
-
-
+Before connecting to a data source, you can configure Drill security features and [secure communication pathways]({{site.baseurl}}/docs/secure-communication-paths/) to a secure Drill cluster. Security features include:
+
+- **Authentication** - Drill supports user authentication to secure clusters with:
+ - Kerberos.
+ See [Kerberos Authentication]({{site.baseurl}}/docs/configuring-kerberos-authentication/).
+ - Username and password (with the Plain mechanism or a Custom Authenticator). See:
+ - [Plain Authentication]({{site.baseurl}}/docs/configuring-plain-authentication/)
+ - [Creating Custom Authenticators]({{site.baseurl}}/docs/creating-custom-authenticators)
+ - Digest
+- **Authorization** - Drill supports restricting an authenticated user's capabilities.
+ See [Configuring User Impersonation with Hive Authorization]({{site.baseurl}}/docs/configuring-user-impersonation-with-hive-authorization/).
+- **Impersonation** - Drill executes queries on behalf of a client while performing the action requested by the client.
+ See:
+ - [Configuring User Impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/)
+ - [Configuring Inbound Impersonation]({{site.baseurl}}/docs/configuring-inbound-impersonation/)
+ - [Configuring User Impersonation with Hive Authorization]({{site.baseurl}}/docs/configuring-user-impersonation-with-hive-authorization/)
+- **Encryption** - Drill does not support encryption as of Drill 1.10.
+
+
+
http://git-wip-us.apache.org/repos/asf/drill/blob/74e0fee7/_docs/configure-drill/securing-drill/070-configuring-user-authentication.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/070-configuring-user-authentication.md b/_docs/configure-drill/securing-drill/070-configuring-user-authentication.md
index e383fb7..e9cdfd0 100644
--- a/_docs/configure-drill/securing-drill/070-configuring-user-authentication.md
+++ b/_docs/configure-drill/securing-drill/070-configuring-user-authentication.md
@@ -1,22 +1,22 @@
---
title: "Configuring User Authentication"
-date: 2017-03-15 00:30:47 UTC
+date: 2017-03-16 01:22:50 UTC
parent: "Securing Drill"
---
Authentication is the process of establishing confidence of authenticity. A Drill client user is authenticated when a drillbit process running in a Drill cluster confirms the identity it is presented with. Drill 1.10 supports several authentication mechanisms through which users can prove their identity before accessing cluster data:
-* **Kerberos** - New in Drill 1.10. See [Kerberos Authentication]({{site.baseurl}}/docs/securing-drill/kerberos-authentication/).
-* **Plain** [also known as basic authentication (auth), which is username and password-based authentication, through the Linux Pluggable Authentication Module (PAM)] - See [Plain Authentication]({{site.baseurl}}/docs/securing-drill/plain-authentication/).
-* **Custom authenticators** - See [Creating Custom Authenticators]({{site.baseurl}}/docs/develop-custom-functions/adding-custom-functions-to-drill/custom-authentication).
-
+* **Kerberos** - New in Drill 1.10. See [Kerberos Authentication]({{site.baseurl}}/docs/configuring-kerberos-authentication/).
+* **Plain** [also known as basic authentication (auth), which is username and password-based authentication, through the Linux Pluggable Authentication Module (PAM)] - See [Plain Authentication]({{site.baseurl}}/docs/configuring-plain-authentication/).
+* **Custom authenticators** - See [Creating Custom Authenticators]({{site.baseurl}}/docs/creating-custom-authenticators).
+
These authentication options are available through JDBC and ODBC interfaces.
-
----
-**Note**
-
-If user impersonation is enabled, Drill executes the client requests as the authenticated user. Otherwise, Drill executes client requests as the user that started the drillbit process. You can enable both authentication and impersonation to improve Drill security. See [Configuring User Impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/) for more information.
-
----
+
+---
+**Note**
+
+If user impersonation is enabled, Drill executes the client requests as the authenticated user. Otherwise, Drill executes client requests as the user that started the drillbit process. You can enable both authentication and impersonation to improve Drill security. See [Configuring User Impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/) for more information.
+
+---
http://git-wip-us.apache.org/repos/asf/drill/blob/74e0fee7/_docs/configure-drill/securing-drill/080-configuring-plain-authentication.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/080-configuring-plain-authentication.md b/_docs/configure-drill/securing-drill/080-configuring-plain-authentication.md
index 8217d58..0beaff6 100644
--- a/_docs/configure-drill/securing-drill/080-configuring-plain-authentication.md
+++ b/_docs/configure-drill/securing-drill/080-configuring-plain-authentication.md
@@ -1,20 +1,20 @@
---
title: "Configuring Plain Authentication"
-date: 2017-03-15 00:30:47 UTC
+date: 2017-03-16 01:22:52 UTC
parent: "Securing Drill"
---
-Linux PAM provides a Plain (or username and password) authentication module that interface with any installed PAM authentication entity, such as the local operating system password file (`/etc/passwd`) or LDAP.
-When using PAM for authentication, each user that has permission to run Drill queries must exist in the list of users that resides on each Drill node in the cluster. The username (including `uid`) and password for each user must be identical across all Drill nodes.
-
-If you use PAM with `/etc/passwd` for authentication, verify that the users with permission to start the Drill process are part of the shadow user group on all nodes in the cluster. This enables Drill to read the `/etc/shadow` file for authentication.
-
-This section includes the following topics:
-
-- [Authentication Process]({{site.baseurl}}/docs/configuring-plain-authentication/#authentication-process)
-- [Connecting with SQLLine]({{site.baseurl}}/docs/configuring-plain-authentication/#connecting-with-sqline)
-- [Connecting with BI Tools]({{site.baseurl}}/docs/configuring-plain-authentication/#connecting-with-bitools)
-- [Installing and Configuring Plain Authentication]({{site.baseurl}}/docs/configuring-plain-authentication/#installing-and-configuring-plain-authentication)
-
+Linux PAM provides a Plain (or username and password) authentication module that interface with any installed PAM authentication entity, such as the local operating system password file (`/etc/passwd`) or LDAP.
+When using PAM for authentication, each user that has permission to run Drill queries must exist in the list of users that resides on each Drill node in the cluster. The username (including `uid`) and password for each user must be identical across all Drill nodes.
+
+If you use PAM with `/etc/passwd` for authentication, verify that the users with permission to start the Drill process are part of the shadow user group on all nodes in the cluster. This enables Drill to read the `/etc/shadow` file for authentication.
+
+This section includes the following topics:
+
+- [Authentication Process]({{site.baseurl}}/docs/configuring-plain-authentication/#authentication-process)
+- [Connecting with SQLLine]({{site.baseurl}}/docs/configuring-plain-authentication/#connecting-with-sqlline)
+- [Connecting with BI Tools]({{site.baseurl}}/docs/configuring-plain-authentication/#connecting-with-bi-tools)
+- [Installing and Configuring Plain Authentication]({{site.baseurl}}/docs/configuring-plain-authentication/#installing-and-configuring-plain-authentication)
+
## Authentication Process
The following image illustrates the PAM user authentication process in Drill. The client passes a username and password to the drillbit as part of the connection request, which then passes the credentials to PAM. If PAM authenticates the user, the connection request passes the authentication phase and the connection is established. The user will be authorized to access Drill and issue queries against the file system or other storage plugins, such as Hive or HBase.
@@ -27,84 +27,84 @@ For more PAM information (including a *JPAM User Guide*), see [JPAM](http://jpam
## Connecting with SQLLine
-When Plain user authentication is enabled with PAM, each user that accesses the drillbit process through a client, such as SQLLine, must provide username and password credentials for access. Users can include the `\u2013n` and `\u2013p` parameters with their username and password when launching SQLLine.
-
-**Example**
-
- sqlline \u2013u jdbc:drill:zk=10.10.11.112:5181 \u2013n bridget \u2013p mypw007!)pwmy
-
-Alternatively, a user can launch SQLLine and then issue the !connect command to hide the password.
-
-1. Start SQLLine on Linux by running the sqlline script.
-
- bridgetsmachine:~$ /etc/drill/bin/sqlline
- apache drill 1.10.0
- "a drill in the hand is better than two in the bush"
-
-1. At the SQLLine prompt, enter the !connect command followed by:
- `jdbc:drill:zk=zk=<zk name>[:<port>][,<zk name2>[:<port>]... `]`
-
- **Example**
-
- `sqlline> !connect jdbc:drill:zk=localhost:2181 scan complete in 1385m`s
-
-1. When prompted, enter a username and password. The password is hidden as it is typed.
-
- Enter username for jdbc:drill:zk=localhost:2181: bridget
- Enter password for jdbc:drill:zk=localhost:2181: *************
-
-## Connecting with BI Tools
-
-To connect to a Drill from a BI tool, such as Tableau, the ODBC driver prompts you for the authentication type, username, and password. For PAM, select **Basic Authenticatio**n in the Authentication Type drop-down menu.
-
-
-
-##Installing and Configuring Plain Authentication
-
-Install and configure the provided Drill PAM for Plain (or username and password) authentication. Drill only supports the PAM provided here. Optionally, you can build and implement a custom authenticator.
-
----
-
-**Note**
-
-Do not point to an existing directory where other Hadoop components are installed. Other file system libraries can conflict with the Drill libraries and cause system errors.
-
----
-
-Complete the following steps to install and configure PAM for Drill:
-
-1. Download the `tar.gz` file for the Linux platform:
-
- `http://sourceforge.net/projects/jpam/files/jpam/jpam-1.1`/
-
-1. Untar the file, and copy the `libjpam.so` file into a directory that does not contain other Hadoop components. For example, `/opt/pam/`
-
-
-1. Add the following line to `<DRILL_HOME>/conf/drill-env.sh`, including the directory where the `libjpam.s`o file is located:
-
- `export DRILLBIT_JAVA_OPTS="-Djava.library.path=<directory>"`
-
- **Example**
-
- `export DRILLBIT_JAVA_OPTS="-Djava.library.path=/opt/pam/"`
-
-1. Add the following configuration to the drill.exec block in `<DRILL_HOME>/conf/drill-override.conf`:
-
- drill.exec {
- security.user.auth {
- enabled: true,
- packages += "org.apache.drill.exec.rpc.user.security",
- impl: "pam",
- pam_profiles: [ "sudo", "login" ]
- }
- }
-
-1. (Optional) To add or remove different PAM profiles, add or delete the profile names in the \u201cpam_profiles\u201d array shown above.
-
-1. Restart the Drillbit process on each Drill node.
-
- `<DRILLINSTALL_HOME>/bin/drillbit.sh restart`
-
+When Plain user authentication is enabled with PAM, each user that accesses the drillbit process through a client, such as SQLLine, must provide username and password credentials for access. Users can include the `\u2013n` and `\u2013p` parameters with their username and password when launching SQLLine.
+
+**Example**
+
+ sqlline \u2013u jdbc:drill:zk=10.10.11.112:5181 \u2013n bridget \u2013p mypw007!)pwmy
+
+Alternatively, a user can launch SQLLine and then issue the !connect command to hide the password.
+
+1. Start SQLLine on Linux by running the sqlline script.
+
+ bridgetsmachine:~$ /etc/drill/bin/sqlline
+ apache drill 1.10.0
+ "a drill in the hand is better than two in the bush"
+
+1. At the SQLLine prompt, enter the !connect command followed by:
+ `jdbc:drill:zk=zk=<zk name>[:<port>][,<zk name2>[:<port>]... `]`
+
+ **Example**
+
+ `sqlline> !connect jdbc:drill:zk=localhost:2181 scan complete in 1385m`s
+
+1. When prompted, enter a username and password. The password is hidden as it is typed.
+
+ Enter username for jdbc:drill:zk=localhost:2181: bridget
+ Enter password for jdbc:drill:zk=localhost:2181: *************
+
+## Connecting with BI Tools
+
+To connect to a Drill from a BI tool, such as Tableau, the ODBC driver prompts you for the authentication type, username, and password. For PAM, select **Basic Authentication** in the Authentication Type drop-down menu.
+
+
+
+##Installing and Configuring Plain Authentication
+
+Install and configure the provided Drill PAM for Plain (or username and password) authentication. Drill only supports the PAM provided here. Optionally, you can build and implement a custom authenticator.
+
+---
+
+**Note**
+
+Do not point to an existing directory where other Hadoop components are installed. Other file system libraries can conflict with the Drill libraries and cause system errors.
+
+---
+
+Complete the following steps to install and configure PAM for Drill:
+
+1. Download the `tar.gz` file for the Linux platform:
+
+ `http://sourceforge.net/projects/jpam/files/jpam/jpam-1.1`/
+
+1. Untar the file, and copy the `libjpam.so` file into a directory that does not contain other Hadoop components. For example, `/opt/pam/`
+
+
+1. Add the following line to `<DRILL_HOME>/conf/drill-env.sh`, including the directory where the `libjpam.s`o file is located:
+
+ `export DRILLBIT_JAVA_OPTS="-Djava.library.path=<directory>"`
+
+ **Example**
+
+ `export DRILLBIT_JAVA_OPTS="-Djava.library.path=/opt/pam/"`
+
+1. Add the following configuration to the drill.exec block in `<DRILL_HOME>/conf/drill-override.conf`:
+
+ drill.exec {
+ security.user.auth {
+ enabled: true,
+ packages += "org.apache.drill.exec.rpc.user.security",
+ impl: "pam",
+ pam_profiles: [ "sudo", "login" ]
+ }
+ }
+
+1. (Optional) To add or remove different PAM profiles, add or delete the profile names in the \u201cpam_profiles\u201d array shown above.
+
+1. Restart the Drillbit process on each Drill node.
+
+ `<DRILLINSTALL_HOME>/bin/drillbit.sh restart`
+
http://git-wip-us.apache.org/repos/asf/drill/blob/74e0fee7/_docs/configure-drill/securing-drill/090-configuring-kerberos-auththentication.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/090-configuring-kerberos-auththentication.md b/_docs/configure-drill/securing-drill/090-configuring-kerberos-auththentication.md
index fa70fca..34b9929 100644
--- a/_docs/configure-drill/securing-drill/090-configuring-kerberos-auththentication.md
+++ b/_docs/configure-drill/securing-drill/090-configuring-kerberos-auththentication.md
@@ -1,43 +1,43 @@
---
title: "Configuring Kerberos Authentication"
-date: 2017-03-15 00:30:47 UTC
+date: 2017-03-16 01:22:54 UTC
parent: "Securing Drill"
---
As of version 1.10, Drill supports Kerberos v5 network security authentication. Kerberos allows trusted hosts to prove their identity over a network to an information system. A Kerberos realm is unique authentication domain. A centralized key distribution center (KDC) coordinates authentication between a clients and servers. Clients and servers obtain and use tickets from the KDC using a special keytab file to communicate with the KDC and prove their identity to gain access to a drillbit. Administrators must create principal (user or server) identities and passwords to ensure the secure exchange of mutual authentication information passed to and from the drillbit.
To use Kerberos with Drill and establish connectivity, use the JDBC driver packaged with Drill 1.10.
----
-**NOTE**
-
-Proper setup, configuration, administration, and usage of a Kerberos environment is beyond the scope of this documentation. See the [MIT Kerberos](http://web.mit.edu/kerberos/ "MIT Kerberos") documentation for information about Kerberos.
-
---
+**NOTE**
+
+Proper setup, configuration, administration, and usage of a Kerberos environment is beyond the scope of this documentation. See the [MIT Kerberos](http://web.mit.edu/kerberos/ "MIT Kerberos") documentation for information about Kerberos.
+
+---
+
+## Prerequisites
+
+The required Kerberos plugin is part of the 1.10 Drill package. You must have a working Kerberos infrastructure, which Drill does not provide. You must be working in a Linux-based or Windows Active Directory (AD) Kerberos environment and have a Drill server configured for Kerberos. See also [Enabling Authentication]({{site.baseurl}}/docs/configuring-kerberos-authentication/#enabling-authentication)
+
+## Client Authentication Process
+
+This section shows a high-level overview of the client authentication process in Kerberos. It is assumed that Kerberos credentials are present in the client.
+
+1. The client sends a request for a ticket granting ticket that contains the user principal to the Kerberos KDC, a network service that supplies tickets and temporary session keys.
-## Prerequisites
-
-The required Kerberos plugin is part of the 1.10 Drill package. You must have a working Kerberos infrastructure, which Drill does not provide. You must be working in a Linux-based or Windows Active Directory (AD) Kerberos environment and have a Drill server configured for Kerberos. See also [Enabling Authentication]({{site.baseurl}}/docs/configuring-kerberos-authentication/#enabling-authentication)
-
-## Client Authentication Process
-
-This section shows a high-level overview of the client authentication process in Kerberos. It is assumed that Kerberos credentials are present in the client.
-
-1. The client sends a request for a ticket granting ticket that contains the user principal to the Kerberos KDC, a network service that supplies tickets and temporary session keys.
-
-1. The authentication server validates the principal\u2019s identity and sends the client a ticket granting ticket and session key encrypted with a secret key. A session key is a temporary encryption key used for one login session.
-
-1. Using the ticket granting ticket, the principal requests access to a drillbit service from the ticket granting server.
-
-1. The ticket granting server checks for a valid ticket granting ticket and the principal identity. If the request is valid, the ticket granting server returns a ticket granting service ticket.
-
-1. The client uses the service ticket to request access to the drillbit.
-
-1. The drillbit service has access to the keytab, a file that contains a list of keys for principals. The key allows the service to decrypt the client\u2019s ticket granting service ticket, identify the principal, and grant access.
+1. The authentication server validates the principal\u2019s identity and sends the client a ticket granting ticket and session key encrypted with a secret key. A session key is a temporary encryption key used for one login session.
+
+1. Using the ticket granting ticket, the principal requests access to a drillbit service from the ticket granting server.
+
+1. The ticket granting server checks for a valid ticket granting ticket and the principal identity. If the request is valid, the ticket granting server returns a ticket granting service ticket.
+
+1. The client uses the service ticket to request access to the drillbit.
+
+1. The drillbit service has access to the keytab, a file that contains a list of keys for principals. The key allows the service to decrypt the client\u2019s ticket granting service ticket, identify the principal, and grant access.
-## Server Authentication Process
+## Server Authentication Process
For Kerberos server authentication information, see the [MIT Kerberos](http://web.mit.edu/kerberos/ "MIT Kerberos") administration documentation.
@@ -51,62 +51,64 @@ Drill must run as a user capable of impersonation. The Kerberos provider in the
---
-
-
-
-
-
-
-1. Create a Kerberos principal identity and a keytab file. You can create one principal for each drillbit or one principal for all drillbits in a cluster. The drill.keytab file must be owned by and readable by the administrator user.
-
- - For a single principal per node in cluster:
-
- # kadmin
- : addprinc -randkey <username>/<FQDN>@<REALM>.COM
- : ktadd -k /opt/mapr/conf/drill.keytab <username>/<FQDN>@<REALM>.COM
-
- (where FQDN is the hostname of the drillbit server. If you have multiple servers, you must create a principal and keytab for each server.)
-
- - For a single principal per cluster, use `<clustername>` instead of `<FQDN>`:
-
- # kadmin
- : addprinc -randkey <username>/<clustername>@<REALM>.COM
- : ktadd -k /opt/mapr/conf/drill.keytab <username>/<FQDN>@<REALM>.COM
-1. Add the Kerberos principal identity and keytab file to the `drill-override.conf` file.
-
- - The instance name must be lowercase. Also, if \_HOST is set as the instance name in the principal, it is replaced with the fully qualified domain name of that host for the instance name. For example, if a drillbit running on `host01.aws.lab` uses `drill/_HOST@<EXAMPLE>.COM` as the principal, the canonicalized principal is `drill/host01.aws.lab@<EXAMPLE>.COM`.
-
- drill.exec {
- security: {
- user.auth.enabled:true,
- auth.mechanisms:[\u201cKERBEROS\u201d],
- auth.principal:\u201cdrill/<clustername>@<REALM>.COM\u201d,
- auth.keytab:\u201c/etc/drill/conf/drill.keytab\u201d
- }
- }
- - To configure multiple mechanisms, extend the mechanisms list and provide additional configuration parameters. For example, the following configuration enables Kerberos and Plain (username and password) mechanisms. See Installing and Configuring Plain Authentication for PAM configuration instructions.
-
- drill.exec: {
- security: {
- user.auth.enabled:true,
- user.auth.impl:"pam",
- user.auth.pam_profile:["sudo", "login"],
- auth.mechanisms:["KERBEROS","PLAIN"],
- auth.principal:"drill/<clustername>@<REALM>.COM",
- auth.keytab:"/etc/drill/conf/drill.keytab"
- }
- }
-
-3 . Restart the drillbit process on each Drill node.
-
- `<DRILLINSTALL_HOME>/bin/drillbit.sh restart`
-
-## Using Connection URLs
-
-In Drill 1.10, Kerberos authentication introduces new URL parameters. The simplest way to connect using Kerberos is to generate a TGT on the client side. In the JDBC connection string, only specify the service principal. For example:
-
- jdbc:drill:
- drillbit=10.10.10.10;
- principal=drill/<serverhostname>@<REALM>.COM
-
-
+
+
+
+
+
+
+1. Create a Kerberos principal identity and a keytab file. You can create one principal for each drillbit or one principal for all drillbits in a cluster. The drill.keytab file must be owned by and readable by the administrator user.
+ - For a single principal per node in cluster:
+
+ # kadmin
+ : addprinc -randkey <username>/<FQDN>@<REALM>.COM
+ : ktadd -k /opt/mapr/conf/drill.keytab <username>/<FQDN>@<REALM>.COM
+
+ (where FQDN is the hostname of the drillbit server. If you have multiple servers, you must create a principal and keytab for each server.)
+
+ - For a single principal per cluster, use `<clustername>` instead of `<FQDN>`:
+
+ # kadmin
+ : addprinc -randkey <username>/<clustername>@<REALM>.COM
+ : ktadd -k /opt/mapr/conf/drill.keytab <username>/<FQDN>@<REALM>.COM
+2. Add the Kerberos principal identity and keytab file to the `drill-override.conf` file.
+
+ - The instance name must be lowercase. Also, if \_HOST is set as the instance name in the principal, it is replaced with the fully qualified domain name of that host for the instance name. For example, if a drillbit running on `host01.aws.lab` uses `drill/_HOST@<EXAMPLE>.COM` as the principal, the canonicalized principal is `drill/host01.aws.lab@<EXAMPLE>.COM`.
+
+ drill.exec {
+ security: {
+ user.auth.enabled:true,
+ auth.mechanisms:[\u201cKERBEROS\u201d],
+ auth.principal:\u201cdrill/<clustername>@<REALM>.COM\u201d,
+ auth.keytab:\u201c/etc/drill/conf/drill.keytab\u201d
+ }
+ }
+ - To configure multiple mechanisms, extend the mechanisms list and provide additional configuration parameters. For example, the following configuration enables Kerberos and Plain (username and password) mechanisms. See Installing and Configuring Plain Authentication for PAM configuration instructions.
+
+ drill.exec: {
+ security: {
+ user.auth.enabled:true,
+ user.auth.impl:"pam",
+ user.auth.pam_profile:["sudo", "login"],
+ auth.mechanisms:["KERBEROS","PLAIN"],
+ auth.principal:"drill/<clustername>@<REALM>.COM",
+ auth.keytab:"/etc/drill/conf/drill.keytab"
+ }
+ }
+
+
+
+
+3 . Restart the drillbit process on each Drill node.
+
+ `<DRILLINSTALL_HOME>/bin/drillbit.sh restart`
+
+## Using Connection URLs
+
+In Drill 1.10, Kerberos authentication introduces new URL parameters. The simplest way to connect using Kerberos is to generate a TGT on the client side. In the JDBC connection string, only specify the service principal. For example:
+
+ jdbc:drill:
+ drillbit=10.10.10.10;
+ principal=drill/<serverhostname>@<REALM>.COM
+
+
http://git-wip-us.apache.org/repos/asf/drill/blob/74e0fee7/_docs/develop-custom-functions/adding-custom-functions-to-drill/015-creating-custom-authenticators.md
----------------------------------------------------------------------
diff --git a/_docs/develop-custom-functions/adding-custom-functions-to-drill/015-creating-custom-authenticators.md b/_docs/develop-custom-functions/adding-custom-functions-to-drill/015-creating-custom-authenticators.md
new file mode 100644
index 0000000..4da469b
--- /dev/null
+++ b/_docs/develop-custom-functions/adding-custom-functions-to-drill/015-creating-custom-authenticators.md
@@ -0,0 +1,105 @@
+---
+title: "Creating Custom Authenticators"
+date: 2016-03-02 00:30:47 UTC
+parent: "Adding Custom Functions to Drill"
+---
+
+
+Administrators can use the template provided here to develop and implement a custom username/password based authenticator.
+
+Complete the following steps to build and implement a custom authenticator:
+
+1. Build the following Java file into a JAR file:
+
+ MyCustomDrillUserAuthenticatorImpl.java
+
+ package myorg.dept.drill.security;
+
+ import org.apache.drill.common.config.DrillConfig;
+ import org.apache.drill.exec.exception.DrillbitStartupException;
+
+ import java.io.IOException;
+
+ /*
+ * Implement {@link org.apache.drill.exec.rpc.user.security.UserAuthenticator} for illustraing how to develop a custom authenticator and use it in Drill
+ */
+ @UserAuthenticatorTemplate(type = \u201cmyCustomAuthenticatorType\u201d)
+ public class MyCustomDrillUserAuthenticatorImpl implements UserAuthenticator {
+
+ public static final String TEST_USER_1 = "testUser1";
+ public static final String TEST_USER_2 = "testUser2";
+ public static final String TEST_USER_1_PASSWORD = "testUser1Password";
+ public static final String TEST_USER_2_PASSWORD = "testUser2Password";
+
+ /**
+ * Setup for authenticating user credentials.
+ */
+ @Override
+ public void setup(DrillConfig drillConfig) throws DrillbitStartupException {
+ // If the authenticator has any setup such as making sure authenticator provider servers are up and running or
+ // needed libraries are available, it should be added here.
+ }
+
+ /**
+ * Authenticate the given <i>user</i> and <i>password</i> combination.
+ *
+ * @param userName
+ * @param password
+ * @throws UserAuthenticationException if authentication fails for given user and password.
+ */
+ @Override
+ public void authenticate(String userName, String password) throws UserAuthenticationException {
+
+ if (!(TEST_USER_1.equals(user) && TEST_USER_1_PASSWORD.equals(password)) &&
+ !(TEST_USER_2.equals(user) && TEST_USER_2_PASSWORD.equals(password))) {
+ throw new UserAuthenticationException(\u201ccustom failure message if the admin wants to show it to user\u201d);
+ }
+ }
+
+ /**
+ * Close the authenticator. Used to release resources. Ex. LDAP authenticator opens connections to LDAP server,
+ * such connections resources are released in a safe manner as part of close.
+ *
+ * @throws IOException
+ */
+ @Override
+ public void close() throws IOException {
+ // Any clean up such as releasing files/network resources should be done here
+ }
+ }
+
+
+2. Create a file named `drill-module.conf` with the following configuration code and then add this file to the root of the JAR file:
+
+ drill {
+ classpath.scanning {
+ packages += "myorg.dept.drill.security"
+ }
+ }
+This enables the custom classpath scanner to locate the new class.
+3. Add the JAR file that you built to the following directory on each Drill node:
+ ` <DRILLINSTALL_HOME>/jars`
+3. Add the following configuration to the `drill.exec` block in the `drill-override.conf` file located in `<DRILLINSTALL_HOME>/conf/`:
+
+ drill.exec {
+ security.user.auth {
+ enabled: true,
+ packages += "myorg.dept.drill.security",
+ impl: "myCustomAuthenticatorType"
+ }
+ }
+4. Restart the Drillbit process on each Drill node.
+
+ <DRILLINSTALL_HOME>/bin/drillbit.sh restart
+
+
+
+
+
+
+
+
+
+
+
+