Default credentials provider should not fail silently if multiple HTTP client are present

[singhbaljit]

Describe the bug

Currently, if both the Apache and URL clients are present on classpath, WebIdentityTokenFileCredentialsProvider will fail with the expected error

Caused by: software.amazon.awssdk.core.exception.SdkClientException: Multiple HTTP implementations 
were found on the classpath. To avoid non-deterministic loading implementations, please explicitly provide 
an HTTP client via the client builders, set the software.amazon.awssdk.http.service.impl system property 
with the FQCN of the HTTP service to use as the default, or remove all but one HTTP implementation 
from the classpath

However, the default credentials provider ignores this error, and moves to the next credential provider. When such exception happens, it indicates that the SDK is configured incorrectly. Ignoring the error implies the STS credentials are not provided, which is not the expected behavior.

Expected Behavior

This error should either not be thrown or not ignored silently.

Current Behavior

Default credentials provider ignores the error WebIdentityTokenFileCredentialsProvider when multiple HTTP clients are present on classpath.

Reproduction Steps

1. Use the default credentials provider to fetch credentials.
2. Add the URL client module on classpath
3. Provide configurations for WebIdentityTokenFileCredentialsProvider
4. The error from WebIdentityTokenFileCredentialsProvider is ignored silently.

Possible Solution

• Throw an exception if the WebIdentityTokenFileCredentialsProvider failed because of incorrect SDK usage with multiple clients.
• Or define a HTTP client explicitly for the STS client so that this exception is not thrown.

Additional Information/Context

This came about when working with awslabs/aws-glue-schema-registry. That library, unlike this SDK, uses the URL client by default instead of the Apache client. See awslabs/aws-glue-schema-registry#120.

AWS Java SDK version used

2.20.162

JDK version used

17.0.8

Operating System and version

Any

[bhoradc]

Hi @singhbaljit,

Thank you for reporting this issue.

I believe this behaviour is per the design. The behaviour of moving onto the next credential provider in the Default credentials provider chain is as expected. The Java SDK can't change its behaviour when there's more than one sync client in the classpath.

You would need to check the logs if an expected credential isn't picked up.

Please let me know if you have further questions. Thank you.

Regards,
Chaitanya

[github-actions]

It looks like this issue has not been active for more than five days. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please add a comment to prevent automatic closure, or if the issue is already closed please feel free to reopen it.

[singhbaljit]

At the INFO level, the default credentials provider actually does not state which underlying credentials provider is being used. So it is difficult to debug, especially in the Kubernetes/STS context. I think the default credentials provider should distinguish between "credentials not available" vs. "SDK is used improperly". Or the very least, print which credentials provider is being at the INFO level.

[singhbaljit]

I created #4631.

[debora-ito]

@singhbaljit we changed the behavior when multiple implementations are found in the classpath, WebIdentityTokenCredentialsProvider won't fail anymore after version 2.22.0, check my comment in #3555 (comment).

In addition, we don't think the logs should have a higher level than DEBUG in this case, so I'll close the PR you submitted.

Let us know if you have any questions.

[singhbaljit]

The changes did fix my issues. Thank you!

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.