In #530 I introduced support for multiple SSO users by reworking our implementation of sso sessions.
When testing this I used a profile which used granted_ prefixes for credential process.
There was a difference in how Granted processed the profile sections.
The issue was that our SSO Assumer would check the value of AWSProfile.SSORegion directly to configure the sso sdk.
This ignored the fact that a profile may be using the AWSPRofile.SSOSession.SSORegion
This behaviour changed when we switched from custom support for session sections to the standard SDK support.
Why?
How did you test it?
I tested this with a profile using granted_ prefixes and one without
This code change also affects/fixes an undetected bug with the --export-all-env-vars flag which would have also exported the wrong ssoRegion and startURL
tested this using assume --export-all-env-vars followed by env | grep AWS
What changed?
Fixes #519
In #530 I introduced support for multiple SSO users by reworking our implementation of sso sessions. When testing this I used a profile which used
granted_prefixes for credential process.There was a difference in how Granted processed the profile sections.
The issue was that our SSO Assumer would check the value of AWSProfile.SSORegion directly to configure the sso sdk. This ignored the fact that a profile may be using the AWSPRofile.SSOSession.SSORegion
This behaviour changed when we switched from custom support for session sections to the standard SDK support.
Why?
How did you test it?
I tested this with a profile using
granted_prefixes and one withoutThis code change also affects/fixes an undetected bug with the --export-all-env-vars flag which would have also exported the wrong ssoRegion and startURL
tested this using
assume --export-all-env-varsfollowed byenv | grep AWSPotential risks
Is patch release candidate?
Link to relevant docs PRs