search

aws / aws-cli

Universal Command Line Interface for Amazon Web Services
Other
15.61k stars 4.14k forks source link

Inconsistent implementations of a hashing function for SSO cached secrets between different SDKs #9035

Open rszymaniak-comscore opened 4 months ago

rszymaniak-comscore commented 4 months ago

Introduction

After successfull SSO auth, a cache is saved to files with with the following path: ~/.aws/sso/cache/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.json, where "xxxxx..." is a hash derived from some fields of a profile.

Describe the problem

It appears that there's no standard way of calculating this hash. Different AWS SDKs have different implementations, to list a few that I've checked (links point directly to implementations):

SDK hash function
botocore sha1 a json containing [sso_start_url or session name], roleName, accountId
aws-sdk-cpp sha1 a sso_start_url
aws-sdk-go (v1) sha1 of sso_start_url
aws-sdk-go-v2 sha1 of sso_start_url
aws-sdk-java-v2 sha1 of sso_start_url
aws-sdk-net sha1 of [sso_start_url OR session name]

See the example below for why exactly this is a problem.

Proposed solution

Enforce a single, standard way of calculating this hash it across all SDKs.

Example instance of this problem

My team uses aws cli (botocore SDK) to authenticate to AWS via SSO, and right now we're trying to configure Nix binary cache which is stored on s3. We're unable to authenticate Nix tool, because Nix (which uses aws-sdk-cpp) can't read secrets created by aws sso login due to a mismatch of secret filenames.

amberkushwaha commented 3 months ago

Add a comment in the ean ti