Solution Web-UI doesn't work due to CORS violations and 403 Errors

[jxn]

Describe the bug After deploying the solution, a blank red banner appears at the top of the page, buttons do not seem to function, and the browser console is full of errors, all related to Cross-Origin-Resource-Sharing policy.

The web-UI url is https://(MYRANDOMSTRING).cloudfront.net/

but multiple references on the page point to https://(SOMEOTHERRANDOMSTRING).execute-api.us-east-1.amazonaws.com/prod/* and there is no associated CORS header to allow this.

To Reproduce Deploy The solution from the Console using the link from the documentation, enter parameters. Visit Web UI cloudfront URI from the Cloudformation Stack Outputs

Expected behavior No CORS errors. Buttons, UI, API functioning when visiting from the cloudfront.net url.

Please complete the following information about the solution:

• [v1.0.5 ] Version: [e.g. v1.0.0]

To get the version of the solution, you can look at the description of the created CloudFormation stack.

For example, "(SO0217) - The AWS CloudFormation hub template for deployment of the Account Assessment for AWS Organisations, Version: v1.0.0".

• [ us-east-1] Region: [e.g. us-east-1]
• [ no] Was the solution modified from the version published on this repository?
• [ ] If the answer to the previous question was yes, are the changes available on GitHub?
• [ no] Have you checked your service quotas for the sevices this solution uses?
• [ no] Were there any errors in the CloudWatch Logs?
• There are some 403s from hitting the endpoints directly, but I think that was me debugging before I noticed CORS errors in the console. CORS would've blocked visiting the endpoint from the embedded src tags before making a request.

Screenshots If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information). Console error

Additional context I configured the solution to deploy in a single account, if that means anything. I omitted the two org/account IDs.

[jxn]

Update: I did some testing to narrow down problems, and I believe I found more problems. I altered my parameters to allow from all IPs rather than just from my own IP, and I was able to find a way to disable CORS enforcement in Chrome and disable cross-origin privacy features.

After doing this, I'm still getting an error banner at the top of the page with no error message in it, and urls to the .execute-api.us-east-1.amazonaws.com/ url are still failing failing with a 403 error (even after logging out/in and deploying with 0.0.0.0/1 allowed cidr parameter)

[tbelmega]

Hi @jxn, thank you for reporting this issue. I'm looking into it!

[tbelmega]

Hi @jxn,

this is likely an authentication problem. The API Gateway is checking the bearer token from the Authorization header of your http request, using the Cognito Authorizer. when Cognito rejects your token, API Gateway generates a 403 response without CORS headers, which the browser interprets as CORS error instead of authentication error. I apologize for the poor user experience, we'll make sure to improve the error handling in the upcoming release v1.1.0. You can verify that the underlying issue is not about CORS by sending an equivalent http request to the API from a tool like cURL or postman instead of the web UI, copying the authentication token from your browsers local storage.

Unfortunately I was not able to reproduce the problem with a fresh deployment of Account Assessment v1.0.5 into my own account, everything seems to work as expected. Can you please confirm in the Amazon Cognito console of your hub account that your user is in state "enabled" and has the user group "FullAccessGroup" attached to it? What I would try out to troubleshoot is (1) open a private browser window and log into the solution UI there, to rule out that any local browser state is interfering (2) create a new cognito user in the same user pool, add the "FullAccessGroup" and try to log in with that user.

[jxn]

@tbelmega I have confirmed that my user was in the Cognito user group FullAccessGroup and was enabled (I did not receive errors during cloudformation deploy and had not manually modified any resources, so this was expected).

I created a new user manually in the same Cognito User Pool and attempted to login through a new Incognito window, and after a successful login (with password reset), I have same result. The web interface displays, but an empty error bar with api requests receiving a 403 error for operations triggered by, for example, the buttons in the UI.

[tbelmega]

The error bar being empty is a bug we have fixed in the upcoming release v1.1.0. If you have an AWS Support plan, I would recommend that you open a support case so that we can help you in detail in your environment. Meanwhile, you can try to find more data on why authentication might be failing through API Gateway access logging or the xray traces of your api call.

[tbelmega]

Hi @jxn, I observed the same behavior (403 error without CORS headers) in case the frontend calls an API endpoint that doesn't exist in API Gateway. Can you double check in API Gateway Service in the AWS Console for one of the failing requests (e.g. GET https://(SOMEOTHERRANDOMSTRING).execute-api.us-east-1.amazonaws.com/prod/delegated-admins) the endpoint exists in the API Gateway? that the url of the API Gateway matches the domain and also the path /delegated-admins is listed under Resources?

[jxn]

@tbelmega I think I discovered the issue. Even when running a check for a subset of accounts, this solution must always be deployed in the org root. I had been deploying this solution to an account lower in the organization hierarchy to test to avoid affecting all accounts, but even when running only against a single account, apparently this is not supported, because the solution discovers the org root and forces its use in role assumption. This makes it impossible to test in another account with a smaller blast radius.

Note that I'm not sure that deploying to the org root would actually affect the some of the CORS issues, but those may not be significant

[tbelmega]

Thank you for the summary!

To clarify, the Hub Stack of the solution can be deployed to any account, but the Org Management stack must always be deployed to the Org Management (org root) account, that is correct. Only from the Org Management account the solution can retrieve the information about delegated admins and trusted access within the organization.

The CORS issues unfortunately obfuscate the underlying issue. We'll address them in v1.1.0.