DefaultStsClient does not add error message from STS response to exception

[drnta]

Describe the bug

When using DefaultStsClient the error mesage from STS response is not included in StsException if the Error element is the root element in STS response.
Sample response from STS:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Error>
    <Code>BadRequest</Code>
    <Message>RoleArn must be at least 20 characters long</Message>
    <Resource>/</Resource>
    <RequestId>4a1c0e2eb20647b1</RequestId>
</Error>

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

Error message from STS response is included in StsException making it easier to understand the problem cause

Current Behavior

(Service: Sts, Status Code: 400, Request ID: 4a1c0e2eb20647b1) (SDK Attempt Count: 1)
software.amazon.awssdk.services.sts.model.StsException: (Service: Sts, Status Code: 400, Request ID: 4a1c0e2eb20647b1) (SDK Attempt Count: 1)
	at software.amazon.awssdk.services.sts.model.StsException$BuilderImpl.build(StsException.java:113)
	at software.amazon.awssdk.services.sts.model.StsException$BuilderImpl.build(StsException.java:61)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.utils.RetryableStageHelper.retryPolicyDisallowedRetryException(RetryableStageHelper.java:168)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.RetryableStage.execute(RetryableStage.java:73)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.RetryableStage.execute(RetryableStage.java:36)
	at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
	at software.amazon.awssdk.core.internal.http.StreamManagingStage.execute(StreamManagingStage.java:53)
	at software.amazon.awssdk.core.internal.http.StreamManagingStage.execute(StreamManagingStage.java:35)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallTimeoutTrackingStage.executeWithTimer(ApiCallTimeoutTrackingStage.java:82)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallTimeoutTrackingStage.execute(ApiCallTimeoutTrackingStage.java:62)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallTimeoutTrackingStage.execute(ApiCallTimeoutTrackingStage.java:43)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallMetricCollectionStage.execute(ApiCallMetricCollectionStage.java:50)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallMetricCollectionStage.execute(ApiCallMetricCollectionStage.java:32)
	at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
	at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ExecutionFailureExceptionReportingStage.execute(ExecutionFailureExceptionReportingStage.java:37)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ExecutionFailureExceptionReportingStage.execute(ExecutionFailureExceptionReportingStage.java:26)
	at software.amazon.awssdk.core.internal.http.AmazonSyncHttpClient$RequestExecutionBuilderImpl.execute(AmazonSyncHttpClient.java:210)
	at software.amazon.awssdk.core.internal.handler.BaseSyncClientHandler.invoke(BaseSyncClientHandler.java:103)
	at software.amazon.awssdk.core.internal.handler.BaseSyncClientHandler.doExecute(BaseSyncClientHandler.java:173)
	at software.amazon.awssdk.core.internal.handler.BaseSyncClientHandler.lambda$execute$1(BaseSyncClientHandler.java:80)
	at software.amazon.awssdk.core.internal.handler.BaseSyncClientHandler.measureApiCallSuccess(BaseSyncClientHandler.java:182)
	at software.amazon.awssdk.core.internal.handler.BaseSyncClientHandler.execute(BaseSyncClientHandler.java:74)
	at software.amazon.awssdk.core.client.handler.SdkSyncClientHandler.execute(SdkSyncClientHandler.java:45)
	at software.amazon.awssdk.awscore.client.handler.AwsSyncClientHandler.execute(AwsSyncClientHandler.java:53)
	at software.amazon.awssdk.services.sts.DefaultStsClient.assumeRole(DefaultStsClient.java:277)
	at software.amazon.awssdk.services.sts.StsClient.assumeRole(StsClient.java:392)

Reproduction Steps

val stsClient = StsClient.builder()
    .region(Region.EU_CENTRAL_1)
    .endpointOverride(URI("<sts_host>"))
    .credentialsProvider(
        StaticCredentialsProvider.create(AwsBasicCredentials.create("<accessKeyId>", "<secretAccessKey>"))
    )
    .build()

val assumeRoleResponse = stsClient.assumeRole(
    AssumeRoleRequest.builder()
        .roleArn("short_arn")
        .roleSessionName(randomUUID().toString())
        .durationSeconds(10800)
        .policy(
            IamPolicy.create(
                listOf(
                    IamStatement.builder()
                        .addPrincipal(IamPrincipal.ALL)
                        .effect(IamEffect.ALLOW)
                        .addAction("s3:ListBucket")
                        .addResource("arn:aws:s3:::bucket")
                        .addCondition(STRING_LIKE, "s3:prefix", "prefix")
                        .build()
                )
            ).toJson()
        )
        .build()
)

Possible Solution

Method getErrorRoot in AwsQueryProtocolFactory may check if the document itself is an Error element.

/**
 * Extracts the <Error/> element from the root XML document. Method is protected as EC2 has a slightly
 * different location.
 *
 * @param document Root XML document.
 * @return If error root is found than a fulfilled {@link Optional}, otherwise an empty one.
 */
Optional<XmlElement> getErrorRoot(XmlElement document) {
    return "Error".equals(document.elementName()) ? Optional.of(document) : document.getOptionalElementByName("Error");
}

Additional Information/Context

No response

AWS Java SDK version used

2.29.52, 2.31.49

JDK version used

openjdk 21.0.7 2025-04-15 LTS

Operating System and version

Windows 11

[debora-ito]

@drnta are you using a third-party endpoint?

I can't reproduce the issue when I send the request to STS, the SDK throws an exception with a message when I run your code sample:

software.amazon.awssdk.services.sts.model.StsException: 1 validation error detected: Value 'arn:aws:iam::123456' at 'roleArn' failed to satisfy constraint: Member must have length greater than or equal to 20 (Service: Sts, Status Code: 400, Request ID: a01d9561-5fda-42c5-894a-c7e9a9df99ef) (SDK Attempt Count: 1)
	at software.amazon.awssdk.services.sts.model.StsException$BuilderImpl.build(StsException.java:113)
	at software.amazon.awssdk.services.sts.model.StsException$BuilderImpl.build(StsException.java:61)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.utils.RetryableStageHelper.retryPolicyDisallowedRetryException(RetryableStageHelper.java:168)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.RetryableStage.execute(RetryableStage.java:73)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.RetryableStage.execute(RetryableStage.java:36)
...

Also based on your request ID format Request ID: 4a1c0e2eb20647b1, it's different than the STS format, I suggest to reach out to the third-party application you're using.

[drnta]

@debora-ito yes, sorry for not mentioning it initially. We are using custom STS which should be S3 compatible.

I suggest to reach out to the third-party application you're using

Could you please help me with the following points to understand how the custom STS can be improved if needed:

1. If possible could you please share the XML response sample from STS based on which the exception in your comment was created
2. Is there any documentation which describes the expected structure of error xml responses from STS? Unfortunately on https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html and https://docs.aws.amazon.com/STS/latest/APIReference/CommonErrors.html there are mostly descriptions of the errors and the sample XML structure is presented only for successfull response.
   I was able to find the sample response and structure for S3 service on https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html#RESTErrorResponses and the structure here exactly matches the structure from the issue description. However this structure seems not being correctly parsed by AwsQueryProtocolFactory#getErrorRoot used by DefaultStsClient because it scans for Error elements only in child elements and does not check the root element itself.

Thanks.

[drnta]

Additionally I checked interaction with the same custom STS using aws-sdk-kotlin version 1.3.112 and it seems to display the error correctly

RoleArn must be at least 20 characters long, Request ID: c5adc3876c224c30
aws.sdk.kotlin.services.sts.model.StsException: RoleArn must be at least 20 characters long, Request ID: c5adc3876c224c30
	at aws.sdk.kotlin.services.sts.serde.AssumeRoleOperationDeserializerKt.throwAssumeRoleError(AssumeRoleOperationDeserializer.kt:57)
	at aws.sdk.kotlin.services.sts.serde.AssumeRoleOperationDeserializerKt.access$throwAssumeRoleError(AssumeRoleOperationDeserializer.kt:1)
	at aws.sdk.kotlin.services.sts.serde.AssumeRoleOperationDeserializer.deserialize(AssumeRoleOperationDeserializer.kt:27)
	at aws.sdk.kotlin.services.sts.serde.AssumeRoleOperationDeserializer.deserialize(AssumeRoleOperationDeserializer.kt:22)
	at aws.smithy.kotlin.runtime.http.operation.DeserializeHandler.call(SdkOperationExecution.kt:347)
	at aws.smithy.kotlin.runtime.http.operation.DeserializeHandler$call$1.invokeSuspend(SdkOperationExecution.kt)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith$$$capture(ContinuationImpl.kt:33)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at kotlinx.coroutines.debug.internal.DebugProbesImpl$CoroutineOwner.<init>(DebugProbesImpl.kt:531)
	at kotlinx.coroutines.debug.internal.DebugProbesImpl.createOwner(DebugProbesImpl.kt:510)
	at kotlinx.coroutines.debug.internal.DebugProbesImpl.probeCoroutineCreated$kotlinx_coroutines_core(DebugProbesImpl.kt:497)
	at kotlin.coroutines.jvm.internal.DebugProbesKt.probeCoroutineCreated(DebugProbes.kt:7)
	at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsJvmKt.createCoroutineUnintercepted(IntrinsicsJvm.kt:161)
	at kotlinx.coroutines.intrinsics.CancellableKt.startCoroutineCancellable(Cancellable.kt:26)
	at kotlinx.coroutines.intrinsics.CancellableKt.startCoroutineCancellable$default(Cancellable.kt:21)
	at kotlinx.coroutines.CoroutineStart.invoke(CoroutineStart.kt:88)
	at kotlinx.coroutines.AbstractCoroutine.start(AbstractCoroutine.kt:123)
	at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:68)
	at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source)
	at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking$default(Builders.kt:48)
	at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source)

The XmlErrorDeserializer in kotlin SDK seems to check both ErrorResponse and Error root elements

[debora-ito]

Here's the XML returned in my local tests:

<ErrorResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
  <Error>
    <Type>Sender</Type>
    <Code>ValidationError</Code>
    <Message>1 validation error detected: Value 'arn:aws:iam::123456' at 'roleArn' failed to satisfy constraint: Member must have length greater than or equal to 20</Message>
  </Error>
  <RequestId>xxx</RequestId>
</ErrorResponse>

I was able to find the sample response and structure for S3 service on https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html#RESTErrorResponses and the structure here exactly matches the structure from the issue description. However this structure seems not being correctly parsed by AwsQueryProtocolFactory#getErrorRoot used by DefaultStsClient because it scans for Error elements only in child elements and does not check the root element itself.

S3 and STS error response bodies can have different shapes because they follow different protocols, S3 uses restXML while STS uses query.

aws-sdk-java-v2/services/sts/src/main/resources/codegen-resources/service-2.json

Line 7 in fc181c7

"protocol":"query",

@drnta as a reminder, we don't guarantee that the Java SDK works with third-party solutions. If you find a repro case where the SDK is having trouble parsing an error sent by STS (not a third-party endpoint), please send us the steps to repro, and we will take a look.

And if you're writing your own custom service, I recommend taking a look at Smithy, it has native support for aws protocols.

[drnta]

@debora-ito thanks for the clarification about the protocol difference.
Looking at restXML protocol errors serialization and query protocol errors serialization looks like indeed restXML protocol accepts both wrapped and non-wrapped errors and query protocol accepts only wrapped.
So I completely agree it is not a bug and understand that SDKs don't guarantee working with non-wrapped error responses for query protocol.

However as I see e.g.

• AWS CLI parses non-wrapped error response from STS with root <Error> tag
• AWS Kotlin SDK parses non-wrapped error response from STS with root <Error> tag because Kotlin codegen for Smithy you mentioned uses same error deserializer for both RestXML protocol and AwsQuery protocol

Wouldn't it be good to have SDKs for different languages behave consistently? If not lets close the issue