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: dev-unsubscribe@drill.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org