[
https://issues.apache.org/jira/browse/DRILL-8056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17475317#comment-17475317
]
ASF GitHub Bot commented on DRILL-8056:
---------------------------------------
jnturton commented on a change in pull request #2401:
URL: https://github.com/apache/drill/pull/2401#discussion_r766654445
##########
File path:
contrib/storage-http/src/main/java/org/apache/drill/exec/store/http/oauth/AccessTokenAuthenticator.java
##########
@@ -0,0 +1,71 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.drill.exec.store.http.oauth;
+
+import lombok.NonNull;
+import okhttp3.Authenticator;
+import okhttp3.Request;
+import okhttp3.Response;
+import okhttp3.Route;
+import org.jetbrains.annotations.NotNull;
Review comment:
Is `NotNull` something different to `NonNull` that came in
intentionally, or did it creep in from a typo? There are occurrences in other
files too.
##########
File path: exec/jdbc-all/pom.xml
##########
@@ -562,7 +562,7 @@
This is likely due to you adding new dependencies to a
java-exec and not updating the excludes in this module. This is important as it
minimizes the size of the dependency of Drill application users.
</message>
- <maxsize>46600000</maxsize>
+ <maxsize>50000000</maxsize>
Review comment:
I still don't completely understand this bit, but should the new
dependencies rather be excluded from the jdbc-all module?
##########
File path: exec/java-exec/src/main/resources/rest/storage/update.ftl
##########
@@ -133,6 +138,71 @@
}
});
+ $("#getOauth").click(function() {
Review comment:
I guess this JS should also be inside a `<#if model.getType() ==
"HttpStoragePluginConfig" >` block if it accesses `#getOauth`?
##########
File path:
logical/src/main/java/org/apache/drill/common/logical/security/CredentialsProvider.java
##########
@@ -33,6 +37,16 @@
* Returns map with authentication credentials. Key is the credential name,
for example {@code "username"}
* and map value is corresponding credential value.
*/
+ static final Logger logger =
LoggerFactory.getLogger(CredentialsProvider.class);
+
@JsonIgnore
Map<String, String> getCredentials();
+
+ @JsonIgnore
+ default void updateCredentials(String key, String value) throws
UserException {
+ throw UserException.internalError()
+ .message("Update credential function not implemented for " + Id.NAME)
+ .build(logger);
+ }
Review comment:
```suggestion
/**
* Set an ephemeral credential. Implementations are not expected to
write this
* value to persistent storage.
*/
@JsonIgnore
void setCredential(String name, String value);
```
##########
File path: contrib/storage-http/OAuth.md
##########
@@ -0,0 +1,122 @@
+# OAuth2.0 Authentication in Drill
+Many APIs use OAuth2.0 as a means of authentication. Drill can connect to APIs
that use OAuth2 for authentication but OAuth2 is significantly more complex
than simple
+username/password authentication.
+
+The good news, and bottom line here is that you can configure Drill to handle
all this automagically, but you do have to understand how to configure it so
that it works. First,
+let's get a high level understanding of how OAuth works. Click here to [skip
to the section on configuring Drill](#configure-drill).
+
+### Understanding the OAuth2 Process
+There are many tutorials as to how OAuth works which we will not repeat here.
There are some slight variations but this is a good enough high level overview
so you will understand the process works.
+Thus, we will summarize the process as four steps:
+
+#### Step 1: Obtain an Authorization Code
+For the first step, a user will have to log into the API's front end, and
authorize the application to access the API. The API will issue you a
`clientID` and a
+`client_secret`. We will use these tokens in later stages.
+
+You will also need to provide the API with a `callbackURL`. This URL is how
the API sends your application the `authorizationCode` which we will use in
step 2.
+Once you have the `clientID` and the `callbackURL`, your application will make
a `GET` request to the API to obtain the `authorizationCode`.
+
+#### Step 2: Swap the Authorization Code for an Access Token
+At this point, we need to obtain the `accessToken`. We do so by sending a
`POST` request to the API with the `clientID`, the `clientSecret` and the
`authorizationCode` we
+obtained in step 1. Note that the `authorizationCode` is a short lived token,
but the `accessToken` lasts for a longer period. When the access token
expires, you may need to
+either re-authorize the application or use a refresh token to obtain a new one.
+
+#### Step 3: Call the Protected Resource with the Access Token
+Once you have the `accessToken` you are ready to make authenticated API calls.
All you have to do here is add the `accessToken` to the API header and you can
make API calls
+just like any other.
+
+#### Step 4: (Optional) Obtain a new Access Token using the Refresh Token
+Sometimes, the `accessToken` will expire. When this happens, the API will
respond with a `401` not authorized response. When this happens, the
application will make a `POST`
+request containing the `clientSecret`, the `clientID` and the `refreshToken`
and will obtain new tokens.
+
+## The Artifacts
+Unlike simple username/password authentication, there are about 5 artifacts
that you will need to authenticate using OAuth and it is also helpful to
understand where they come
+from and to whom they "belong". Let's start with the artifacts that you will
need to manually obtain from the API when you register your application:
(These are not the Drill
+config variables, but the names are similar. More on that later.)
+* `clientID`: A token to uniquely identify your application with the API.
+* `clientSecret`: A sort of password token which will be used to obtain
additional tokens.
+* `callbackURL`: The URL to which access and refresh tokens will be sent. You
have to provide this URL when you register your application with the API. If
this does not match
+ what you provide the API, the calls will fail.
+* `scope`: An optional parameter which defines the scope of access request
for the given access token. The API will provide examples, but you have to pick
what accesses you
+ are requesting.
+
+You will need to find two URLs in the API documentation:
+
+* `authorizationURL`: This is the URL from which you will request the
`authorizationCode`. You should find this in the API documentation.
+* `tokenURL`: The URL from which you can request the `accessToken`.
+
+There are two other artifacts that you will need, but these artifacts are
generated by the API. One thing to note is that while all the other artifacts
are owned by the
+application, these two are unique (and "owned by") the user. These artifacts
are:
+* `accessToken`: The token which is used to grant access to a protected
resource
+* `refreshToken`: The token used to obtain a new `accessToken` without having
to re-authorize the application.
+
+Currently, Drill does not allow per-user credentials. However, it is possible
to configure Drill to use the Vault Credential Provider so that each individual
user has their
Review comment:
I don't think this is the case...
##########
File path:
exec/java-exec/src/main/java/org/apache/drill/exec/store/security/CredentialProviderUtils.java
##########
@@ -43,4 +43,59 @@ public static CredentialsProvider getCredentialsProvider(
}
return new PlainCredentialsProvider(mapBuilder.build());
}
+
+ /**
+ * Constructor for OAuth based authentication. Allows for tokens to be
stored in whatever vault
Review comment:
I think we can avoid having all of this OAuth-specific code show up here
like this, by a universally-supported `setCredential()`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
> Add OAuth2 Support for HTTP Rest Plugin
> ---------------------------------------
>
> Key: DRILL-8056
> URL: https://issues.apache.org/jira/browse/DRILL-8056
> Project: Apache Drill
> Issue Type: Improvement
> Components: Storage - Other
> Affects Versions: 1.19.0
> Reporter: Charles Givre
> Assignee: Charles Givre
> Priority: Major
> Fix For: 1.20.0
>
>
> Many enterprise platforms use OAuth2 for authentication and authorization.
> This pull request allows Drill to authenticate with external APIs that use
> OAuth2 and query these data sources.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
