jmklix
commented
4 months ago We never added support for SSO profile-defined credentials to this repo, so this is not expected to work. This is something that we would like to add in the future, but I don't have a timeframe for when it might be added. Changing this to a feature request.
adabir2
Describe the bug
NOTE: This has also been raised as https://github.com/awslabs/aws-c-auth/issues/228 - but not knowing where ownership lies, I'm raising here also for visibility.
Short Version
aws_credentials_provider_new_chain_default doesn't account for SSO credentials configuration in an INI profile, and this appears to be a bug rather than an unimplemented feature.
Long Version
Coming from https://github.com/awslabs/aws-crt-nodejs, all of the AWS guidance for Sig4(a) signing HTTP requests in JavaScript is to use the
aws-crtpackage, which is backed byaws-c-auth.The options in that package's sign function expect a self-defined credentials provider generated by the NAPI-exposed functions labelled
newDefault,newStatic,newCognitoandnewX509.The expectation, and all available guidance, is that you should use
aws-crt.auth.AwsCredentialsProvider.newDefault()if you want/need to source credentials from the default provider chain, and it is expected that this will mirror the behaviour of other implementations, sourcing credentials from the environment, from local profile, from ECS and then IMDS etc.However, when the aws-crt package calls
aws_credentials_provider_new_chain_defaultfrom aws-c-auth, between aws_profile.c and credentials_provider_profile.c, there does not appear to be any call to the credentials_provider_sso.c implementation, or attempt to load sso-specific configuration properties from the profile.I have been focussing heavily on the SSO functionality, but I suspect this is also true for other credential providers that are normally invoked from the use of specific property names in a profile configuration, for example the
processprovider.This issue is especially confusing as while there's no specific indication that SSO is not supported through a profile configuration, the library explicitly contains code for interpreting and managing SSO-sourced credentials.
We are now working around this issue by taking a leaf from
@aws-sdk/client-s3's book, and sourcing credentials ourselves (using@aws-sdk/credential-providers//fromNodeProviderChain()), and then passing those credentials intonewStatic, bypassing the chain-lookup native to these packages, however it has taken a lot of time and effort to understand the nature of the problem and decide upon the workaround.Documentation regarding expectations of the default provider chain for AWS SDKs and tools: https://docs.aws.amazon.com/sdkref/latest/guide/feature-sso-credentials.html
Expected Behavior
Given valid SSO credentials in the local credentials cache, generated by an SSO profile being configured, active and logged in, the credentials should be used to SigV4a sign a request when present and the Default provider chain is requested as a credentials provider.
Current Behavior
Relevant Debug Logs from aws-crt:
Reproduction Steps
Given
~/.aws/configAnd
And
Then
sign.tsShould Output
Should Not Output
Possible Solution
My understanding of the exact structure of the code is limited, but I believe it is a matter of configuring the new_default provider chain to include the use of the sso credentials provider already present in the code, when the sso_session property is configured in a profile.
Additional Information/Context
This is how we are now working around this problem.
Credentials are looked up using fromNodeProviderChain() and passed hardcoded to newStatic().
This is aligned to the approach taken in
@aws-sdk/client-s3: https://github.com/aws/aws-sdk-js-v3/blob/5afac5e175e7b0a92cd612c5a4730a4269c4fa52/packages/signature-v4-crt/src/CrtSignerV4.ts#L281However because we are not informed enough to presume what might be supported in the
newDefaultchain that may not be supported infromNodeProviderChain, we fall back tonewDefaultin the eventfromNodeProviderChainis unable to provide credentials. This potentially duplicated failed chain sources, but is more robust in handling future expectations from either package.aws-crt-nodejs version used
v1.21.0
nodejs version used
v20.5.1
Operating System and version
Linux 5.15.94 #1 SMP PREEMPT x86_64 13th Gen Intel(R) Core(TM) i7-13850HX GenuineIntel GNU/Linux