Custom `user-agent` not propagated to nested STS client

[jackrein]

Checkboxes for prior research

• I've gone through Developer Guide and API reference
• I've checked AWS Forums and StackOverflow.
• I've searched for previous similar issues and didn't find any solution.

Describe the bug

When using role chaining, the custom user agent on the outer client is not propagated to the nested STS client.

Regression Issue

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

SDK version number

3.911.0

Which JavaScript Runtime is this issue in?

Node.js

Details of the browser/Node.js/ReactNative version

v18.20.2

Reproduction Steps

1. Create the following content in ~/.aws/config file:

   [profile second]
   credential_process=/usr/bin/get-credentials
   region=us-west-2
   
   [profile first]
   source_profile=second
   role_arn=arn:aws:iam::123456789012:role/Role

2. Use the SDK with the first role: AWS_PROFILE=first npm run start (start invokes the following script)

   import { S3Client, ListBucketsCommand } from '@aws-sdk/client-s3';
   
   const s3Client = new S3Client({
       defaultUserAgentProvider: () => Promise.resolve(["my-user-agent", "1"]), // or customUserAgent
       logger: {
           ...console
       }
   });
   const command = new ListBucketsCommand({});
   const response = await s3Client.send(command);

Observed Behavior

Observe two AWS requests in CloudTrail. The AssumeRole request retains the default user-agent. The ListBuckets request contains the custom user agent:

1. aws-sdk-js/3.911.0 ua/2.1 os/darwin#24.6.0 lang/js md/nodejs#18.20.2 api/sts#3.911.0 m/E,w,v vs
2. my-user-agent m/E,T,i,o

Expected Behavior

Both requests contain the my-user-agent m/E,T,i,o user agent value.

Possible Solution

Propagate the custom user agent values to the nested STS client.

Note: other configuration to the outer client, like custom middleware, is not propagated to the nested client as well

Additional Information/Context

No response

[kuhe]

You should be able to use the clientConfig option of whatever credential provider you're using. The default one for Node.js is https://www.npmjs.com/package/@aws-sdk/credential-providers#fromnodeproviderchain.

import { fromNodeProviderChain } from "@aws-sdk/credential-providers"; 

const credentialProvider = fromNodeProviderChain({
  // This provider accepts any input of fromEnv(), fromSSO(), fromTokenFile(),
  // fromIni(), fromProcess(), fromInstanceMetadata(), fromContainerMetadata()
  // that exist in the default credential chain.

  // Optional client overrides. This is passed to an inner credentials client
  // that may be STS, SSO, or other instantiated to resolve the credentials.
  // Region and profile are inherited from the upper client if present
  // unless overridden, so it should not be necessary to set those.
  //
  // Warning: setting a region here may override the region set in
  // the config file for the selected profile if profile-based
  // credentials are used.
  clientConfig: {
    defaultUserAgentProvider
  },
});

new Client({
  credentials: credentialProvider
});

[jackrein]

That didn't work for me either. If I am understanding the code correctly, it doesn't propagate arbitrary configurations to the nested client–only a select few properties

stsClient = new STSClient({
    profile: stsOptions?.parentClientConfig?.profile,
    // A hack to make sts client uses the credential in current closure.
    credentialDefaultProvider: () => async () => closureSourceCreds,
    region: resolvedRegion,
    requestHandler: isCompatibleRequestHandler ? (requestHandler as any) : undefined,
    logger: logger as any,
});

[kuhe]

We discussed the issue and the patch will be to allow the clientConfig to work as intended: #7445.

The full clientConfig was not being passed to the inner STS client in the assume role branch of the credential resolution process. Only the fields described above in @jackrein 's comment were being passed through.

[jackrein]

With version 3.914.0, this is fixed, for the most part.

import { S3Client, ListBucketsCommand } from '@aws-sdk/client-s3';
import { fromNodeProviderChain } from '@aws-sdk/credential-providers';

const s3Client = new S3Client({
    customUserAgent: [["MyUserAgent, 1.0.0"]],
    credentials: fromNodeProviderChain({
        clientConfig: {
            customUserAgent: [["MyUserAgent", "1.0.0"]]
        }
    })
});

const command = new ListBucketsCommand({});
const response = await s3Client.send(command);

The above script gives the following user agents

1. For the AssumeRole: aws-sdk-js/3.914.0 ua/2.1 os/darwin#24.6.0 lang/js md/nodejs#18.20.2 api/sts#3.914.0 m/E,w,v MyUserAgent/1.0.0
2. For the ListBuckets: [aws-sdk-js/3.914.0 ua/2.1 os/darwin#24.6.0 lang/js md/nodejs#18.20.2 api/s3#3.914.0 m/E,T,i,o,e MyUserAgent--1.0.0]

They are slightly different though. The second user agent is in brackets, with a MyUserAgent--1.0.0 value instead of a MyUserAgent/1.0.0 value like in the first one. Any idea why?

[kuhe]

Released in https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.914.0. I'll comment later on the brackets.