auto-normalize sso start url

[trondhindenes]

when pasting an sso start url into bash/zsh, it gets formatted to https://myorg.awsapps.com/start/\#/ It seems that the trailing #/ is important, and using a url without it causes the sso session to not be valid.

I propose that aws-sso-util should auto-normalize urls (basically auto-replace /start/\#/ with /start/#/) to make it easier.

[benkehoe]

I don't think that's feasible. The trailing #/ is a URL fragment that currently seems to be added during the login process in the browser, but is not relevant to identifying an AWS SSO instance in configuration; it should work with https://myorg.awsapps.com/start at least (which is the "official" start URL); I'm not sure about https://myorg.awsapps.com/start/.

In general, since the normalization of start URLs is not documented, I am reluctant to apply any normalization to it. Maybe aws-sso-util check could look for it and suggest that it might be a problem?

[trondhindenes]

Interesting. If I do:
AWS_DEFAULT_SSO_START_URL="https://myorg.awsapps.com/start" AWS_DEFAULT_SSO_REGION=eu-central-1 BROWSER=chromium aws-sso-util roles, the "login dance" succeeds but I don't end up with a valid aws session.

However, if I proceed to run AWS_DEFAULT_SSO_START_URL="https://myorg.awsapps.com/start#/" AWS_DEFAULT_SSO_REGION=eu-central-1 BROWSER=chromium aws-sso-util roles
and retry an aws command, it succeeds.

This leads me to believe that while aws-sso-util doesn't care, the aws cli requires an exact match on the sso_start_url attribute in ~/.aws/config. So, if users specify the url with trailing hash/slash when running aws-sso-util configure then that url gets stamped in users' config file, and subsequent aws-sso-util runs need to get passed a sso url that exactly matches it. My thought was that aws-sso-util could be made a little smarter by performing normalization or maybe even lookups on the sso_start_url in /.aws/config to aid users in getting the url right.

This all comes into effect only when there's more than one SSO url at play and aws-sso-util requires some kind of hint as to what sso url to work with.

[benkehoe]

Aha! So what's happening here is that the cache files in ~/.aws/sso/cache have a filename that is a hash of the start URL. So any byte-level differences in the start URL are going to result in different hashes. So when you login using https://myorg.awsapps.com/start#/, it caches the result in a file using a hash of that. But a profile in ~/.aws/config that uses https://myorg.awsapps.com/start as its start URL is going to look for a different cache file name, which it doesn't find. I don't think there's a good way around this. Perhaps aws-sso-util check, which looks for all the different SSO configs you have, can look for similarity and say, "hey, you've got multiple URLs that look similar; if they are supposed to be the same, any differences is going to cause problems"

Separately, if you only have one value for start URL in your ~/.aws/config, it's not necessary to set AWS_DEFAULT_SSO_START_URL. If you've got multiple, the "hint" doesn't need to be a full URL, if it doesn't start with http it's interpreted as a regex. So you could do AWS_DEFAULT_SSO_START_URL=myorg (and not set the region env var) if you've got start_url = https://myorg.awsapps.com/start in a profile somewhere.

[trondhindenes]

nice, thanks for looking into it! Yep, all of this started when I started working with multiple customers using aws sso. It all works perfectly when there's only a single sso org in the config. I'll try the wildcard matcher!