SSO login doesn't report an error when a user cannot assume a role on an account

[onitake]

Confirm by changing [ ] to [x] below to ensure that it's a bug:

• [x] I've gone though the User Guide and the API reference
• [x] I've searched for previous similar issues and didn't find any solution

Describe the bug When authenticating to AWS SSO with a valid identity, SSO will always report success. It does not report an error if the specified role cannot be assumed.

SDK version number 2.1.35

Platform/OS/Hardware/Device Debian bullseye

To Reproduce (observed behavior)

1. Have an account that is managed by AWS SSO
2. Have a role that is assigned to this account in AWS SSO
3. Have a user identity that can authenticate with AWS SSO, but that is not authorized to use this role on this account
4. Create a corresponding profile in ~/.aws/config
5. Run aws sso login
6. Authenticate in the web browser

Expected behavior The browser or the CLI should report an error that login was successful, but that the role cannot be assumed on the account.

Logs/output Both the browser and CLI report success. Running any AWS CLI commands afterwards will fail; even aws sts get-caller-identity will report an error and not display any identity information.

Additional context Since neither the CLI nor the AWS SSO login portal display any information about the users identity, it's very hard to debug this issue if you don't know what to look for. The user may already have an cookie set on their identity provider or have auto-login enabled through GSSAPI. In this case, they would immediately be logged in without any interaction.

Some environments may require users to use multiple identities, making the problem even more cumbersome.

[stobrien89]

Hi @onitake,

Thanks for reaching out! Just to make sure we're on the same page, you see this occurring when you run other AWS CLI commands after a sso login for a user that is not granted access to the permission set/role that is specified in the SSO configuration profile? This is what I receive when attempting to do the same:

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

This is expected behavior, but I can see how it would be difficult to debug. Ideally, in this scenario, the browser would report the error (that the role cannot be assumed), but we don't handle anything on the browser side and I'm not sure if it's possible for a test assume-role call to be performed in that capacity. This would require further research and collaboration between the CLI and SSO teams. Marking as a feature request for now.

[stobrien89]

Hi @onitake,

I reviewed with the team and this is something we're not opposed to working on, but it would be helpful if you could provide more information on specifically when/how you've encountered this when using SSO login. Details about your profile configuration would be helpful as well.

[github-actions[bot]]

Greetings! It looks like this issue hasn’t been active in longer than a week. We encourage you to check if this is still an issue in the latest release. Because it has been longer than a week since the last update on this, and in the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or add an upvote to prevent automatic closure, or if the issue is already closed, please feel free to open a new one.

[dreams-and-thoughts]

I've just run into this problem.

The error:

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

Initially this occurred on version 2.1.29, so I upgraded, but the issue persisted.

aws --version
aws-cli/2.2.43 Python/3.8.8 Darwin/20.6.0 exe/x86_64 prompt/off

Profile:

[profile mts-dev]
sso_start_url = https://company.awsapps.com/start#/
sso_region = {region}
sso_account_id = 635803*****
sso_role_name = AdministratorAccess
region = {region}

I'm still trying to figure out why this has started happening. I'm not aware of any changes to our SSO configuration, or my local machine setup.

[dreams-and-thoughts]

I've found the issue with my setup. It was an incorrect sso_start_url parameter.

A few weeks ago we migrated to a new SSO account/directory, and a new URL.

For some reason it's taken this long for the URL in my .aws/config file to cause an issue... Seems strange. Not sure if that would be reproducible or not.

I guess it would still be useful if there was some feedback in cases like this.

[stobrien89]

Thanks for sharing @comfytoday— Glad you were able to track down the cause. Just to confirm, this was the result of an account mismatch?

[dreams-and-thoughts]

Yes, I think that is accurate. The sso_start_url was no longer correct, as the account I was attempting to login to had been moved to a different organisation.

What's interesting is that the account was moved days (weeks?) earlier, and I'd been using the sso login command in the interim. Is that even possible?? I'm not sure...

The original sso_start_url was still valid, but for the wrong organisation. Also, to complicate things, my passwords are actually the same between the organisations, so it appeared to work correctly from the browser perspective.

Let me know if you need any clarification on anything.

[stobrien89]

Hi @comfytoday,

Thanks for the clarification!

What's interesting is that the account was moved days (weeks?) earlier, and I'd been using the sso login command in the interim. Is that even possible?? I'm not sure...

I think what happened is that the client registration (found in ~/.aws/sso/cache was valid for the interim you specified— The clientId and clientSecret are valid for 90 days from the first login and are refreshed once expired.

[taha23hasnain]

Faced this same issue today. This was due to a Permission Set mismatch in the config file. Was able to pick it up rather easily as the only thing we changed were permissions but error handling needs to be better. The error thrown is not really descriptive and does not include much details. Very misleading too as you start questioning IAM permissions instead of a misconfiguration in your profile.

[spawar1991]

Hi @stobrien89,

Today, I faced the similar issue. I have performed "aws configure sso" command and it executed successfully. After that, I have authenticated using "aws sso login --profile <profile_name>" command. Since, I have multiple profiles I have called specific profile.

After both the steps are successful, when I perform "aws sts get-caller-identity --profile test-master", it throws an error saying"

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

[profile test-master] sso_start_url = https://*******sso.awsapps.com/start#/ sso_region = us-east-1 sso_account_id = 931698@@@@@@ sso_role_name = AdministratorAccess region = us-west-2

I'm not able to understand what's causing this issue? I'm not aware of any changes to our SSO configuration, or my local machine setup.

[nl-brett-stime]

This can also happen if the role name changes.

If you get, An error occurred (ForbiddenException) when calling the GetRoleCredentials operation: No access, it's probably best to double-check all/each of the SSO attributes in the profile:

• sso_start_url
• sso_region
• sso_account_id
• sso_role_name

In our case, an administrator had clarified the role name in the cloud. The change was mostly seamless so nobody was notified about the change but it did break access for those of us with that role who make remote calls from our workstations. That is to say, even if you don't think anything changed, it's still a good idea to cross-check against your console access.

[Loverboylove]

Okay team I get it !

[BwL1289]

If it helps someone, we recently changed our sso_start_url. I updated my config with the new URL and began receiving this error.

Then, I changed the URL back to the original in my config, logged in, and it worked.

Then, I changed it back to the new URL in my config, logged in, and it worked.

[benkehoe]

I don't really think that aws sso login should check for access, as the token it should receive and cache isn't credentials for a particular account and role, and it shouldn't go get those until it attempts to access that account and role for a particular purpose. The command aws sso login --profile my-profile doesn't and shouldn't use the sso_account_id and sso_role_name fields (especially since #5727).

But, a command in the AWS CLI to help debug access issues would be great, something like aws sso debug --profile my-profile. I've made such a thing in my third party tool aws-sso-util called aws-sso-util check, but I'd much prefer to see something built in to the AWS CLI.

[janaka]

+1 these error messages are misleading. It makes a config file problem appear like a permissions problem.

[benkehoe]

With the new Identity Center sessions configuration (link to docs), it's more explicit that aws sso login is not accessing a particular account and role:

[sso-session my-session]
sso_start_url = https://example.awsapps.com/start
sso_region = us-east-2
sso_registration_scopes = sso:account:access

[profile my-profile-1]
sso_session = my-session
sso_account_id = 111122223333
sso_role_name = MyRole1
region = us-west-2

[profile my-profile-2]
sso_session = my-session
sso_account_id = 444455556666
sso_role_name = MyRole2
region = us-west-2

then it's

# Log in to example.awsapps.com/start
$ aws sso login --sso-session my-session
# Use a particular account and role by using a profile
$ aws sts get-caller-identity --profile my-profile-1

[saivariam]

I'm also encountering similar issue while trying to use Terraform after AWS sso login. I'm able to successfully log in to AWS SSO using the AWS CLI, and running terraform init also works. However, when I run terraform plan or terraform import, I get the following error:Error: configuring Terraform AWS Provider: validating provider credentials: retrieving caller identity from STS: operation error STS: GetCallerIdentity, https response error StatusCode: 403, RequestID: 173b371b-ae2c-4674-a761-1b7c16b74d5d, api error InvalidClientTokenId: The security token included in the request is invalid. I suspect its the same issue as others have encountered. I tried using aws sts get-caller-identity and the response was An error occurred (ForbiddenException) when calling the GetRoleCredentials operation: No access Is it really that my credentials that are changed and i still use old one, if that is the case then how aws sso login succeeds.

[saivariam]

Ok for me the issue is resolved by changing the role_name, I was using wrong sso_role_name and now aws sts get-caller-identity gets me the correct identity and all aws cli commands are accessible.

[juliencol]

Hey I seem to also be experiencing this issue or a very similar one. My config file looks like this.

[sso-session session]
sso_start_url = https://example.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

[profile profile-1]
sso_account_id = 111122223333
sso_role_name = Role1
region = us-east-1
output = json
sso_session = session

[profile profile-2]
sso_account_id = 111122223333
sso_role_name = Role2
region = us-east-1
output = json
sso_session = session

Then I run the following commands to refresh my session and access my roles.

• aws sso logout - This operation succeeds. It doesn't return anything.
• aws sso login --sso-session session - This operation succeeds. It opens a browser window and then confirms I'm logged in.
• aws sts get-caller-identity --profile profile-1 - This operation succeeds. It returns the expected Role1 permission set.
• aws sts get-caller-identity --profile profile-2 - This operation fails. It returns a ForbiddenException error: An error occurred (ForbiddenException) when calling the GetRoleCredentials operation: No access.

I do have access to both Role1 and Role2 permission sets when I open the AWS console in a browser tab. I'm only experiencing this error once in a while. I'm sometimes able to access my second role and sometimes can't, without changing anything in my config file. I've tried logging in profiles instead of sessions and create a session for each profile but no luck. Role1 permission set session duration is set to 12h. Role2 permission set session duration is set to 1h.

[janaka]

I don't know if this helps. I login to the aws console with SSO (Google apps). Then aws sso login --profile <myprofile>. It then does the the browser redirect thing, I don't have to interact any further. If I don't login to the console first I get prompted to enter a code in the browser. When I enter the code emitted by the CLI, it gives a handled error in the browser. My profile and session is configured the same as yours.

[nightspotlight]

What's helped me was to go through SSO configuration again in AWS CLI:

aws sts get-caller-identity --profile my-profile 

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

aws sso logout --profile my-profile

aws sts get-caller-identity --profile my-profile

Error loading SSO Token: Token for my-sso-session does not exist

aws configure sso
# chose existing my-sso-session
# when prompted, set profile name to my-profile

aws sts get-caller-identity --profile my-profile
# this time i got the expected creds json

[ungarida]

For me the problem was the role name. Not because it changed but just because I was using the IAM Role name instead here it is needed the name as it looks like on the Identity Center > Permission Sets.