feat(java/driver/flight-sql): add OAuth2 support#4290
feat(java/driver/flight-sql): add OAuth2 support#4290lxyzxx wants to merge 1 commit intoapache:mainfrom
Conversation
xborder
left a comment
xborder
left a comment
There was a problem hiding this comment.
I think arrow-java has all the primitives required to implement this. If we can leave most of the resposabilities to arrow-java, it would be great.
It already knows how to create the configurations, client creation, managing oauth.
Maybe ArrowFlightSqlClientHandler.Builder is too focused on JDBC so it could be worth decoupling it a bit
|
|
||
| import org.checkerframework.checker.nullness.qual.Nullable; | ||
|
|
||
| public enum OAuthFlowType { |
There was a problem hiding this comment.
nimbus already had this in its API. Maybe we could add nimbus as a dependency and use GrantType.CLIENT_CREDENTIALS/GrantType.TOKEN_EXCHANGE instead of creating our own
|
|
||
| package org.apache.arrow.adbc.driver.flightsql.oauth; | ||
|
|
||
| public enum OAuthTokenType { |
There was a problem hiding this comment.
Similarly to GrantType comment, we can use nimbusds TokenTypeURI
| String authorizationHeader = null; | ||
| String username = null; | ||
| String password = null; | ||
| String oauthFlow = null; | ||
| if (parameters != null) { | ||
| for (Map.Entry<String, Object> parameter : parameters.entrySet()) { | ||
| if (parameter.getKey().startsWith(FlightSqlConnectionProperties.RPC_CALL_HEADER_PREFIX)) { | ||
| String userHeaderName = | ||
| parameter | ||
| .getKey() | ||
| .substring(FlightSqlConnectionProperties.RPC_CALL_HEADER_PREFIX.length()); | ||
|
|
||
| if (parameter.getValue() instanceof String) { | ||
| callHeaders.insert(userHeaderName, (String) parameter.getValue()); | ||
| } else if (parameter.getValue() instanceof byte[]) { | ||
| callHeaders.insert(userHeaderName, (byte[]) parameter.getValue()); | ||
| } else { | ||
| throw new AdbcException( | ||
| String.format( | ||
| "Header values must be String or byte[]. The header failing was %s.", | ||
| parameter.getKey()), | ||
| null, | ||
| AdbcStatusCode.INVALID_ARGUMENT, | ||
| null, | ||
| 0); | ||
| } |
There was a problem hiding this comment.
Should we use ArrowFlightSqlClientHandler.Builder to create the flight client with all the configurations?
I think it would simplify the configuration, creating and managing the flight client
2 participants
This change follows the earlier discussion in #4272.
Now that Arrow Java 19.0.0 has been merged, Java ADBC Flight SQL can reuse the OAuth2 support already implemented in Arrow Java. This commit wires that existing Arrow Java OAuth2 implementation into the Java ADBC Flight SQL driver, instead of introducing a separate OAuth implementation on the ADBC side.
What changed
client_credentialstoken_exchangeAdbcExceptionstatus codes during connection setupFlightClienton failed authentication / handshake pathsUsage notes
For
client_credentials, configure:adbc.flight.sql.oauth.flowadbc.flight.sql.oauth.token_uriadbc.flight.sql.oauth.client_idadbc.flight.sql.oauth.client_secretFor
token_exchange, use the correspondingadbc.flight.sql.oauth.exchange.*properties.OAuth token endpoint HTTPS validation follows the Arrow Java / JVM SSL behavior and uses the JVM SSL configuration, such as:
javax.net.ssl.trustStorejavax.net.ssl.trustStorePasswordjavax.net.ssl.trustStoreTypeFlight server TLS continues to use the existing ADBC Flight SQL TLS connection properties.
Token refresh / re-acquisition is delegated to the reused Arrow Java OAuth provider and happens on demand when a valid token is needed for a request.
Validation
client_credentialsagainst a local Keycloak setup