Preserve AWS_CREDENTIALS during auth scheme resolution

[S-Saranya1]

Motivation and Context

Previously some customers override AWS credentials for specific requests by setting AwsSignerExecutionAttribute.AWS_CREDENTIALS in their execution interceptors. After moving auth scheme resolution from interceptors to a dedicated pipeline stage (#6755), these interceptor-set credentials were being ignored.

This happened because after moving auth scheme resolution to a pipeline stage, credentials are now freshly resolved in AuthSchemeResolutionStage. Since this stage runs after all interceptors, the freshly resolved credentials replace whatever the interceptor had set via AWS_CREDENTIALS.

Modifications

Fix 1:

Updated IdentityProviderUpdater to accept ExecutionAttributes and check for interceptor-set AWS_CREDENTIALS before resolving credentials. If an interceptor has set credentials, they are wrapped in a StaticCredentialsProvider and used instead of the default provider.

Credentials are resolved in this priority order:

1. Request-level override via AwsRequestOverrideConfiguration.credentialsProvider()(Not respected before, this refactoring fixes it)
2. Interceptor-set AwsSignerExecutionAttribute.AWS_CREDENTIALS (deprecated, preserved for backwards compatibility)
3. Client-configured credentials provider (default)

This matches the behavior before the migration.

Changes:

• IdentityProviderUpdater — added executionAttributes parameter to the update method
• AwsIdentityProviderUpdater — added check for deprecated AWS_CREDENTIALS execution attribute
• AuthSchemeResolutionStage — passes execution attributes to the updater
• EndpointResolutionStage — null-safe port comparison in interceptorModifiedEndpoint

Fix 2 : Fixed NPE in EndpointResolutionStage on null port

Fixed a NullPointerException in EndpointResolutionStage when comparing request ports. The port can be null when no explicit port is set, and the comparison was not null-safe.

Testing

Verified with existing unit test in IdentityResolutionOverrideTest which covers credential override scenarios including interceptor-set AWS_CREDENTIALS, request-level overrides, and default credentials provider fallback.

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
• 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

[dagnir]

Can this be replaced with Objects.equals()?

[S-Saranya1]

Hmm, when no port is set, the SDK returns null but URI.getPort() returns -1, so Objects.equals() would be incorrect and needs special handling for this when no port is set case. So just skipping the comparison when port is null.

[dagnir]

Ah I see!

[github-actions]

This pull request has been closed and the conversation has been locked. Comments on closed PRs are hard for our team to see. If you need more assistance, please open a new issue that references this one.