Skip to content

Conversation

@himadripal
Copy link
Contributor

@himadripal himadripal commented Feb 29, 2024

@himadripal
Copy link
Contributor Author

himadripal commented Feb 29, 2024

Although the issue discusses about making audience configurable but there are few other optional parameter exists in the specification (i.e resource,actor_token etc. ) which are not configurable right now. This is an attempt to make all optional OAuth params configurable. Idea is if you have those optional parameters configured in properties, we build map out of it, picking only optional params from the properties and pass it along.
scope is also an optional parameter, I think it can also be moved to using this map.
@nastra @rdblue @syun64 Please take a look and provide feedback. @RussellSpitzer @flyrain as well

@himadripal
Copy link
Contributor Author

Can I get someone's attention for a review on this one please?

@flyrain
Copy link
Contributor

flyrain commented Mar 4, 2024

Thanks @himadripal for working on it. Let me take a look.

Copy link
Contributor

@flyrain flyrain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @himadripal working on it. LGTM overall. Left some comments.

ConfigResponse config;
OAuthTokenResponse authResponse;
String credential = props.get(OAuth2Properties.CREDENTIAL);
// CONSIDER : putting scope in optional param map - reduce wiring on scope
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, we should have a Java class synced with the OAuthClientCredentialsRequest in Rest spec. It'd be nice to pass around an object of the class. The class itself can even be autogenerated. Also by doing it this way, the Java code is always synced with spec. And every time we made a change like this, only the spec needs to be changed. cc @nastra

However, that's fairly a big change. We will potentially need to deprecate some methods. Another option is to put every optional parameter(including scope, token type) in a map at this PR, then refactor it later.

WDYT? Also cc @danielcweeks @nastra @syun64

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will also need an update on spec for these optional parameters, but I'm OK with another PR.

Copy link
Contributor Author

@himadripal himadripal Mar 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, we should have a Java class synced with the OAuthClientCredentialsRequest in Rest spec

A java class for all optional params is good suggestion, that way, we can implement individual parameter level default and validation if needed.

However, that's fairly a big change. We will potentially need to deprecate some methods. Another option is to put every optional parameter(including scope, token type) in a map at this PR, then refactor it later.

Yes, this will need changes in public API and deprecate some methods. I tried putting scope in the map and some of the tests were failing, I'll take a look again. How about we put all the optional param mentioned here in the map including scope and I'll create an issue for removing scope as individual param.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking a bit more. The second option(putting the scope into the optional params) also needs to deprecate several methods, e.g., exchangeToken(), fetchToken(), etc, since their signatures will change. I think it's not worthy to do that now given that we will refactor later to use a OAuthClientCredentialsRequest object. Let's move forward with this approach.

Comment on lines +215 to +221
ImmutableMap.of(),
token,
null,
credential(),
SCOPE,
oauth2ServerUri(),
optionalOAuthParams())));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we extract this part so that the following one at line 231 can reuse it?

Copy link
Contributor Author

@himadripal himadripal Mar 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one in line 231, do not have token provided (token = null), we can still create a private method with token as param, but this one looks more readable. WDYT?

@himadripal
Copy link
Contributor Author

himadripal commented Mar 6, 2024

Does all of these optional parameters need to be added in the OAuthTokenResponse as well? @flyrain

Copy link
Contributor

@flyrain flyrain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1. Thanks @himadripal for working on it. As a followup, would you mind create issues?

  1. Adding audience, resource in the rest spec.
  2. Enriching Rest catalog configure doc with more options, in spark-configuration.md, we usually use the spark as the reference implementation, so it's OK to only change the spark side.

ConfigResponse config;
OAuthTokenResponse authResponse;
String credential = props.get(OAuth2Properties.CREDENTIAL);
// CONSIDER : putting scope in optional param map - reduce wiring on scope
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking a bit more. The second option(putting the scope into the optional params) also needs to deprecate several methods, e.g., exchangeToken(), fetchToken(), etc, since their signatures will change. I think it's not worthy to do that now given that we will refactor later to use a OAuthClientCredentialsRequest object. Let's move forward with this approach.

@nastra
Copy link
Contributor

nastra commented Mar 8, 2024

overall I think adding these optional OAuth2 params make sense to me. I'll also link to the OAuth2 spec for other reviewers to better understand what those optional parameters do.
I think we should decide how we want to deal with AuthSession configuration paramters as it causes lots of changes to add a single parameter to AuthSession.

@himadripal himadripal force-pushed the feature_make_oauth_audiance_configurable branch from ee89988 to 47da67a Compare March 11, 2024 19:29
@flyrain
Copy link
Contributor

flyrain commented Mar 11, 2024

+1 Thanks @himadripal for the PR. Thanks @nastra for the review.

@flyrain flyrain merged commit 5f655a3 into apache:main Mar 11, 2024
tomtongue pushed a commit to tomtongue/iceberg that referenced this pull request Mar 12, 2024
szehon-ho pushed a commit to szehon-ho/iceberg that referenced this pull request Sep 16, 2024
zachdisc pushed a commit to zachdisc/iceberg that referenced this pull request Dec 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants