- Newest
- Most votes
- Most comments
The permission set relay state is for redirecting to an AWS management console URL, like https://<region>.console.aws.amazon.com/systems-manager/managed-instances?region=<region>#. The sign-in URL is a separate service endpoint, which is likely why HTTP 400 errors are occurring. Maybe, you want to consider a purpose-built redirect page with a matrix of switch role URLs that could be integrated with AWS SSO as a cloud app. This may be more scalable in the long run as you map many roles in external accounts to many AWS SSO users.
I was able to get the relay state to work with https://us-east-1.console.aws.amazon.com/iamv2/home#/roles. That URL should work if the permission set has IAM privileges.
+1 on this feature. Seems the whole point to do after SSO login is to do Switch role. But currently everything is static and is a bocker to create deep link logins with AWS SSO
Relevant content
- asked 2 years ago
- Accepted Answerasked a month ago
- asked a year ago
- AWS OFFICIALUpdated 4 months ago
- AWS OFFICIALUpdated a year ago
- What's the difference between Lambda function execution role permissions and invocation permissions?AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
Thanks for your response, but it doesn't help with what we are trying to accomplish. This is the flow that I am looking for:
1.) User logs into SSO Portal 2.) User clicks Management Console for specific Permission Set 3.) User is routed to the "Switch Role" interface (https://signin.aws.amazon.com/switchrole) 4.) Fields are already populated with target account's ID and role name to be assumed
The "Link to switch roles in console" listed when a role is created is exactly what we need, if only it would work as a Relay State URL.