[feature] Multiple Identity Center / SSO Session support

[joshrivers]

Is your feature request related to a problem? Please describe.
I have a situation where I need to manage separate AWS Identity Center connections independently (and potentially simultaneously). Currently go-aws-sso cannot hanle more than one login at a time, as the Identity Center/SSO tokens get stored in a single file with a hard-coded path.

Describe the solution you'd like
I would like the tool to be able to manage separate access token files for separate SSO sessions.

Describe alternatives you've considered
I have a proof-of-concept hack which provides an optional CLI flag to override the default access-token.js path. This solves for my basic use case, but aligning token file storage with credentials profiles manually. At the minimum, the profile probably needs to be written with the flag/path when the tool writes it to the file. This is probably the quickest way to add the functionality, but may be a bit awkward to explain, document, and use (and it requires semi-manual management of the token file names).

I started looking at the awscli [sso-session] configurations typically stored in .aws/config. I wonder if it would make sense to leverage those, rather than directly having the user decide on access token file path names. The CLI flag could then be based on the session name, rather than the cache file location. Conceivably, using the sso-session config could supplement, override, or replace the go-aws-sso/config.yml file.

This leads to a second thought about researching whether we could use/share the .aws/sso/cache files that are generated by aws sso login. At a glance it just looks like there are minor marshalling differences and the file name is based on a hash of the session name and start url, but there may have been Good Reasons why this tool was designed to ignore those files?

Additional context
Is it worthwhile to honor the AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE environment variables? This isn't directly relevant to solving my issue, but I could imagine scenarios where overriding the location for these files would allow the tool to be used in multiple contexts.

I'm willing to put some time into implementation, and I have some further thoughts and discussion on implementation details, but I want to make sure the scope of this functionality is desirable in the tool before getting too far into the weeds.

[theurichde]

Hi there @joshrivers. Thanks for opening this issue, and deep sorry for the late reply.

Your feature request makes totally sense to me.

but there may have been Good Reasons why this tool was designed to ignore those files?

I wanted to have go-aws-sso to be independent of any 3rd party application (especially the aws cli with its Python dependencies)

Is it worthwhile to honor the AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE environment variables

It is!

whether we could use/share the .aws/sso/cache files that are generated by aws sso login

That would be fine for me, so go-aws-sso could act as a drop-in replacement and can leverage existing config.

Happy to hear your thoughts on that!

[joshrivers]

I wanted to have go-aws-sso to be independent of any 3rd party application (especially the aws cli with its Python dependencies)

Exactly why I love it, too.

That would be fine for me, so go-aws-sso could act as a drop-in replacement and can leverage existing config.

Happy to hear your thoughts on that!

Excellent. I haven't done a thorough analysis yet, because I didn't want to presume that I could take the tool in a different direction without asking and I didn't want to do throwaway work.

What I'm thinking of doing:

1. Determining a method of having more than one ClientInfo / access-token file. Preferably this will mean using the same file naming and creation scheme used by the official CLI.
   a) I will probably need to come up with an answer to "is this a 'breaking'" change or a backwards-compatible one. Perhaps it will be easy to re-use the existing session file while also supporting the new file format and location. Perhaps users will need to do a one-time re-login on upgrade.
   b) Presumably the new file locations would be preferred for future use, but it is conceivable that both mechanisms could be maintained side-by-side and usage determined on configuration.
2. Since you like the idea of supporting the official config/credentials file, I would want to implement alternative SSO endpoints and configs by reading sso-session sections from the config files. I think these would be selected by a new flag on calls to the assume command.
   a) To be determined: which config source has precedence if both exist for the default SSO Session.
   b) Is it desirable to have first-run for go-aws-sso just use the SSO start-urls from .aws/config?
   c) I think there would be support for writing to .aws/config as well as .aws/credentials. The goal would be to have this non-conflicting with the current AWS CLI usage of those files.
3. In the process of implementing the above, I would like to do some refactoring in internal/aws.go and pkg/sso/ to make setup some boundaries between the components, use struct-and-method patterns and some interfaces to inject dependencies, and make things a bit more testable. This will probably address [refactoring] Evaluate frequent usage of zap.Fatal() #163 and I may clean up [feature] Read Start URL and Region via Environment Variables #12. It might be a breaking change on [feature] Expose an API for sso process as a package #65, (but I'd hope it makes the library API cleaner)

I think I have some additional small features and/or bugfixes in my notes. I guess we should decide if a bigger refactor/feature MR is a good thing, or if I should do some more work to layer the above into multiple MRs so that too much doesn't change at once. I expect that I'll have solid testing, so I don't expect breakage, but I can put in the extra effort if you'd rather have several phases of review rather than a single bigger MR.

[theurichde]

First: Thanks for sticking around and investing so much time!

1. A breaking change is not a problem for me. People can choose to not upgrade - they won't miss any new core functionality. And folks can handle manual one-time re-logins, I am pretty sure 🤞🏻

2.a) see b)
2.b) Mhh. I tend to no. I would not expect to have it watching for 3rd party config files - but it would be okay if we say we are going to cannibalize this file and make it go-aws-sso exclusive, meaning we use it, we write it, we override it.
2.c) Totally agree

3. Go ahead! I am looking forward to it!

PR size: You decide. I can handle both. A bigger one may take a bit longer (with discussions etc.) - but would be easier for you.

Thanks!

[joshrivers]

Hey @theurichde, I wanted to give you an update. I had gotten a day or two into my refactor and was looking up some API details when I tripped over aws-sso-cli. I was excited for a few minutes, thinking I'd be able to grab some implementation details and hints from their implementation...then I was sad, because it looks like that project has implemented just about every feature and enhancement that I was looking to add to go-aws-sso. I was enjoying doing the code work, but for now I think I'm going to use the synfinatic CLI to solve my SSO needs rather than work up a redundant implementation.

Thanks for the invitation to contribute.

[hwong557]

I found granted to be useful as well: https://docs.commonfate.io/granted/getting-started