Skip to content

Conversation

@gosar
Copy link
Contributor

@gosar gosar commented Mar 10, 2023

Motivation and Context

As part of SRA, earlier PR added the new interfaces. This PR updates existing code to accept and use the new interfaces.

Modifications

This PR updates existing interfaces like AwsClientBuilder and others where customers used to be able to provide AwsCredentialsProvider, to be able to provide the new interface - IdentityProvider<? extends AwsCredentialsIdentity>.

Pending:

  • Code generator changes for endpoint discovery case - SyncClientClass.
  • I'm still working on adding tests.
  • Also need to update few more classes like AwsCredentialsProviderChain called out in design doc, and confirm if there are any more places. But to wrap up this PR and not make it bigger, will do that in separate PR.
  • Will update code for new Token interfaces later too, in separate PR.
  • Potentially move CREDENTIALS_IDENTITY_PROVIDER into SdkClientBuilder to support generic clients using AWS Credentials. Maybe in separate PR.

Testing

Updated existing tests. Added new tests.

Screenshots (if appropriate)

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Checklist

  • I have read the CONTRIBUTING document
  • Local run of mvn install succeeds
    Ran ./mvnw clean install -pl :auth,:aws-core,:s3,:polly,:rds -am -Pquick locally
  • My code follows the code style of this project
  • My change requires a change to the Javadoc documentation
  • I have updated the Javadoc documentation accordingly
  • I have added tests to cover my changes
  • All new and existing tests passed
  • I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
  • My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

  • I confirm that this pull request can be released under the Apache 2 license

In AwsClientBuilder and other places where customers used to be able to provide
AwsCredentialsProvider.
@gosar gosar force-pushed the gosar/sra-ia-identity-overload-3 branch from 342c987 to 8ac22a4 Compare March 10, 2023 21:23
Comment on lines 39 to 40
// TODO: Can the type be changed to IdentityProvider? This class is @SdkProtectedApi
public static final ExecutionAttribute<AwsCredentials> AWS_CREDENTIALS = new ExecutionAttribute<>("AwsCredentials");
Copy link
Contributor

Choose a reason for hiding this comment

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

We might be able to get away with it if we did a minor version bump and told customers we'll be breaking protected APIs, but we probably want to save that until the Smithy code generator migration, where we'll likely have to start breaking a lot of protected things.

For now, is there a way to add an AWS_CREDENTIALS_IDENTITY and support both of them? (AWS_CREDENTIALS for old consumer versions and AWS_CREDENTIALS_IDENTITY for new ones?) We could add a TODO comment or annotation for these things we want to clean up with the Smithy code generator migration so that we can make sure we don't forget them?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, I put this comment as I thought I may make some changes to signer code to accept the new types as part of this PR, but Anna-Karin and I decided we can tackle that in part of the signer changes. And for now using toCredentials when interfacing with the signer code. As part of signer changes we can add AWS_CREDENTIALS_IDENTITY and support both, with a TODO comment as you said. For now, same comment applies to AwsClientOption.AWS_CREDENTIALS I think, so added a TODO there. Using a // smithy codegen TODO: convention. LMK if you have a different suggestion for that.

Copy link
Contributor Author

@gosar gosar left a comment

Choose a reason for hiding this comment

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

There are a few comments from Matt still pending, but responding with some here.

return config.option(AwsClientOption.CREDENTIALS_PROVIDER) != null
? config.option(AwsClientOption.CREDENTIALS_PROVIDER)
private IdentityProvider<? extends AwsCredentialsIdentity> resolveCredentialsIdentityProvider(SdkClientConfiguration config) {
// Note, that CREDENTIALS_PROVIDER is never set. It is replaced with CREDENTIALS_IDENTITY_PROVIDER, so just check that
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, given your comment above, for older clients, we need to set CREDENTIALS_PROVIDER, so putting this comment at the definition of the option would be confusing. Given the comment above, I'm going to remove this comment here and instead add a comment above explaining why CREDENTIALS_PROVIDER is being set. LMK if you think I should comment things differently.

Comment on lines -67 to +69
AwsCredentialsProvider defaultCredentialsProvider = clientConfiguration.option(AwsClientOption.CREDENTIALS_PROVIDER);
IdentityProvider<? extends AwsCredentialsIdentity> defaultCredentialsProvider =
clientConfiguration.option(AwsClientOption.CREDENTIALS_IDENTITY_PROVIDER);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, similar to another comment, my thought on this being in the same aws-core module as AwsDefaultClientBuilder, makes me wonder if CREDENTIALS_IDENTITY_PROVIDER will still be set for older clients, that use the newer aws-core? Maybe there are other code paths or something I'm not thinking through.

@gosar gosar marked this pull request as ready for review March 31, 2023 22:34
@gosar gosar requested a review from a team as a code owner March 31, 2023 22:34
Comment on lines +35 to +37
// smithy codegen TODO: This could be removed when doing a minor version bump where we told customers we'll be breaking
// protected APIs. Postpone this to when we do Smithy code generator migration, where we'll likely have to start
// breaking a lot of protected things.
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we put this somewhere that it doesn't mess up the javadoc for this field?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's in comments, so shouldn't affect javadoc. Either ways, if you think I should do something different here, lmk.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, I thought that since this comment separated the field from the javadoc that it would mess up the rendering.

@sonarqubecloud
Copy link

sonarqubecloud bot commented Apr 1, 2023

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 33 Code Smells

73.3% 73.3% Coverage
4.2% 4.2% Duplication

@gosar gosar merged commit 53f5cb3 into feature/master/sra-identity-auth Apr 3, 2023
@gosar gosar deleted the gosar/sra-ia-identity-overload-3 branch April 3, 2023 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants