aws2 cli sso login should give option to force new session entirely

[gfcroft]

Is your feature request related to a problem? Please describe. one problem I have encountered with AWS SSO is that when a user has already been mapped against an account, and is then assigned a new permission set against that account via being added to a group which has a permission set against that account, they must log out and log in again in order to be able to access these permissions

Specifically, I experienced this when I was added to a new SSO group with an additional permission set, against an account I already had a permission set mapped to (AWSAdministratorAccess). aws sso login seemingly logged me in on the cli - but I had an old browser session somewhere which hadn't invalidated its session (i.e. I had an existing session which didn't have the new permission set in). attempts to use the new permission set on the CLI failed with:

botocore.exceptions.ClientError: An error occurred (ForbiddenException) when calling the GetRoleCredentials operation: No access

An error occurred (ForbiddenException) when calling the GetRoleCredentials operation: No access

because the cli seems to be taking the same permissions as my old browser session (which is my default browser). It took a frustratingly long while to find that the cli doesn't actually update the session when one does aws sso login (and they have an existing sso session open on a browser) and that the only way for my cli to be able to access the new permissions was to log out on the browser and then log in again, then do aws sso login again

Describe the solution you'd like enable the aws cli to be able to invalidate the old session (everywhere) and force a new session as an additional option to aws sso login; e.g.:

aws sso login --fresh

[kdaily]

Hi @georgewheatcroft,

Thanks for your post. I tried this out, but I could use the new permission set just fine. I had an existing SSO user with one permission set. I logged in via the command line, using a profile like this:

[profile test_user]
sso_start_url=https://d-12345da678.awsapps.com/start
sso_region=us-west-2
sso_account_id=123456789012
sso_role_name=AdministratorAccess
region=us-west-2
output=json

Through the AWS console, I associated another permission set to this user account, added another profile to my config file like:

[profile test_user]
sso_start_url=https://d-12345da678.awsapps.com/start
sso_region=us-west-2
sso_account_id=123456789012
sso_role_name=DatabaseAdministrator
region=us-west-2
output=json

I could then run commands just fine using this new role permission set, without logging in or out again. I'm wondering if there's some other issue, or something else that I'm missing here. I don't think the CLI would have any way to invalidate browser sessions as it does not manage those.

[gfcroft]

Sorry @kdaily I have a slightly different workflow where I am experiencing this (I've also edited my original comment for clarity):

1. assign your sso user directly against an account by mapping it to the account with a permission set.(e.g. AWSAdministratorAccess) - you should be able to see this on the sso console "your applications" landing page after refreshing the page
2. now create an SSO group and associate that with the account and a different permission set (e.g. AWSPowerUserAccess) - add your sso user to that group, you should see that on the "your applications" landing page that the permission set this group grants hasn't appeared yet (one would need to log out and log back in, in order for this to happen seemingly)
3. without logging out and in on your web browser beforehand, enter aws sso login in your terminal, click allow on the resulting google chrome auth page, now attempt to use a profile which uses that role in your config - e.g.

   [profile test_user]
   sso_start_url=https://d-12345da678.awsapps.com/start
   sso_region=us-west-2
   sso_account_id=123456789012
   sso_role_name=AWSPowerUserAccess
   region=us-west-2
   output=json

aws sts get-caller-identity  --profile test_user

should fail with:

botocore.exceptions.ClientError: An error occurred (ForbiddenException) when calling the GetRoleCredentials operation: No access

An error occurred (ForbiddenException) when calling the GetRoleCredentials operation: No access

because I think aws sso login on the cli doesn't actually cause a fresh login session to occur, because it doesn't actually trigger the termination/invalidation of the currently running user session that the browser is using

I can appreciate this could perhaps require a few changes, but in my view the cli should have the power to invalidate a login session (across all clients one may be using) in order to prevent issues such as the case above (where one needs to log out and in, in order for the change to take effect in SSO) - for me it just feels a bit wrong for a new aws sso login attempt on the cli not to be able to deliver this, and for cli users to be effectively stuck with a 'stale' login session until they log in and out on the browser - this can cause difficulties for developers using the cli in this circumstance, until of course their web browser session finally expires, in which case they then may be very surprised to see that the cli then works after a new aws sso login attempt !

[joguSD]

The code backing the aws sso login command actually does have a "fresh" option force_refresh and it's always applied: https://github.com/aws/aws-cli/blob/99a32dda2fac3b4ff3523980e0367508f8d3d4e5/awscli/customizations/sso/login.py#L41-L46

So every aws sso login invocation derives a new access token to the best of our ability given the exposed APIs.

There's some rather unintuitive ties between sessions vended from the SSO endpoints and the sessions in the browser (e.g. logging out in the browser can invalidate the session the CLI got, etc.) and I'm assuming this is another one of those rough edges.

[kdaily]

@georgewheatcroft,

I could reproduce your scenario. I'm going to check in with the SSO team to see if I can get some clarification on the behavior.

[kdaily]

Hi @georgewheatcroft, no update to report. Since this seems to be an SSO implementation issue, I'm going to move this ticket to the SDK repository, aws/aws-sdk for tracking.

[kdaily]

P42423194

[kdaily]

@georgewheatcroft,

~Can you confirm that you still experience this behavior? I tried it again after pinging for an update, and running aws sso logout now invalidates the browser session as well. I'm prompted to log in again without logging out of the browser manually.~

Strike that, I can still reproduce.

[ashishdhingra]

Reached out to service team for an update. Awaiting response.