'sso-session' name is not compatible with awscli_v2

[pznamensky]

Describe the bug

When there is a whitespace in sso session name, aws configure sso generates ~/.aws/config where sso-session section include session name with apostrophes, which is not recognised by aws sdk.

Expected Behavior

aws sdk is compatible with the config which aws configure sso generates

Current Behavior

aws sdk can't parse the config file with this error:
"failed to find SSO session section"

Reproduction Steps

• invoke aws configure sso and type session name with whitespace
• use aws sdk with newly created profile

Possible Solution

No response

Additional Information/Context

aws configure sso generates the following ~/.aws/config config:

[profile AdministratorAccessLimited-123]
sso_session = My Corp Ltd
sso_account_id = 123
sso_role_name = AdministratorAccessLimited
region = eu-west-1
[sso-session 'My Corp Ltd']
sso_start_url = https://some-url.awsapps.com/start#/
sso_region = eu-west-2
sso_registration_scopes = sso:account:access

If we remove apostrophes in sso-session section, everything will work fine:

...
[sso-session My Corp Ltd]
...

It looks like the fix is to add optional checking for apostrophes here:

aws-sdk-go-v2/config/shared_config.go

Line 877 in 1cc8d04

section, ok := sections.GetSection(ssoSectionPrefix + strings.TrimSpace(c.SSOSessionName))

AWS Go SDK V2 Module Versions Used

github.com/aws/aws-sdk-go-v2 v1.21.0
github.com/aws/aws-sdk-go-v2/feature/ec2/imds v1.13.11
github.com/aws/aws-sdk-go-v2/feature/s3/manager v1.11.83
github.com/aws/aws-sdk-go-v2/service/dynamodb v1.21.1
github.com/aws/aws-sdk-go-v2/service/s3 v1.38.5
github.com/aws/smithy-go v1.14.2

Compiler and Version used

1.21.1

Operating System and version

ubuntu 22.04

[lucix-aws]

Checking with the CLI folks on this -- the quoting of the profile they generate is technically out of spec to my understanding, but my guess is they're not going to be able to get away with changing that behavior.

[RanVaknin]

After reviewing this with the team we have confirmed that the CLI is not behaving according to the shared config file specification, and therefore we are not going to mimic this same incorrect behavior.

Thank you for reaching out.
All the best,
Ran~

[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.