AWS Builder Center

Builder Center

Federated Cross-Account Access to WorkSpaces applications Using IAM Identity Center and Entra ID

Learn how to enable cross-account access to AWS WorkSpaces Applications using IAM Identity Center and Microsoft Entra ID. This article covers configuring SAML federation in a central account, establishing IAM trust in a workload account, setting up cross-account attribute mappings, and validating the streaming session — with reference architecture and workflow diagrams.

Shantanu Nitin Padhye

Authors :

Shantanu Padhye : Sr SA Agentic WorkSpaces
 Lakshmi Radhakrishnan  : SA Agentic WorkSpaces

Introduction :
Customers running AWS Organizations often centralize identity management in a single account using AWS IAM Identity Center (IDC). When Microsoft Entra ID serves as the external identity provider with SAML and SCIM, users get seamless single sign-on to AWS resources.
But what happens when the WorkSpaces Applications stacks live in a different AWS account? This article walks through a tested, end-to-end configuration that lets users authenticate through IAM IDC in a central account and stream applications from a secondary account — all without duplicating identity infrastructure.
Architecture Overview

The solution spans two AWS accounts:

  • Account A (Central / Management) — Hosts the organization-level IAM Identity Center instance with Microsoft Entra ID configured as the external identity provider and SCIM provisioning enabled.
  • Account B (Workload / Secondary) — Hosts the WorkSpaces Applications fleet, stack, and associated resources (images, VPC, etc.).
Prerequisites :
  • AWS Organizations with IAM Identity Center enabled in the management (or delegated admin) account.
  • Microsoft Entra ID configured as the external identity provider with SCIM provisioning enabled.
  • A WorkSpaces Applications stack already created in Account B (the secondary account).
The authentication flow works as follows:
  1. A user navigates to the IAM IDC access portal (e.g.,  https://d-a267f9af02.awsapps.com/start ).
  1. IAM IDC redirects to Microsoft Entra ID for authentication.
  1. After successful sign-in, the user sees the assigned WorkSpaces Applications tile.
  1. Clicking the tile triggers a SAML assertion that includes the cross-account IAM Role ARN and Identity Provider ARN from Account B.
  1. AWS STS in Account B validates the assertion, assumes the role, and redirects the user to the WorkSpaces Applications stack via the relay state URL.
  1. The streaming session starts.

Step-by-Step Configuration :
Step 1 — Configure IAM Identity Center with Microsoft Entra ID (Account A)

Set up IAM Identity Center in your central account with Entra ID as the external identity provider. Enable SCIM provisioning so users and groups sync automatically. If you've already completed this, move to the next step.
For detailed guidance, see  Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center .

Step 2 — Add a WorkSpaces Applications SAML Application in IAM IDC (Account A)

In the IAM Identity Center console :
  1. Navigate to Applications → Add application.
  1. Select I want to select an application from the catalog and search for Amazon WorkSpaces Applications.
  1. Choose Next and configure the application.
Under Application properties, configure:
  • Relay state:  https://appstream2.euc-sso.<REGION>.aws.amazon.com/saml?stack=<STACK_NAME>&accountId=<ACCOUNT_B_ID> 
  • Replace  <REGION>  with the AWS Region where your stack resides (e.g.,  us-east-1 ).
  • Replace  <STACK_NAME>  with the exact name of your WorkSpaces Applications stack in Account B.
  • Replace  <ACCOUNT_B_ID>  with the 12-digit AWS account ID of Account B (no hyphens).
  • Session duration: 1 hour (or your preferred value).
Under Application metadata, select Manually type your metadata values and enter:
  • Application ACS URL:  https://signin.aws.amazon.com/saml 
  • Application SAML audience:  urn:amazon:webservices 

Step 3 — Download the IAM IDC SAML Metadata (Account A)

On the application configuration page, locate the IAM Identity Center metadata section. Download the IAM Identity Center SAML metadata file. You'll upload this file in Account B to establish the trust relationship.
Tip: You can also copy the metadata URL directly if your IAM provider creation workflow supports URL-based import.

Step 4 — Create a SAML Identity Provider in IAM (Account B)

Sign in to Account B and navigate to the IAM console:
  1. Go to Identity providers → Add provider.
  1. Select SAML as the provider type.
  1. Give the provider a descriptive name (e.g.,  IAMIdentityCenter-AccountA ).
  1. Upload the SAML metadata file you downloaded in Step 3.
  1. Choose Add provider and note the Provider ARN.
For detailed steps, see  Create a SAML Identity Provider in AWS IAM .

Step 5 — Create an IAM Role for SAML Federation (Account B)

Create a SAML 2.0 federation IAM role in Account B:
  1. In the IAM console, choose Roles → Create role.
  1. Select SAML 2.0 federation as the trusted entity type.
  1. Choose the SAML provider you created in Step 4.
  1. For Attribute, select  SAML:sub_type . For Value, enter  persistent .
  1. Complete the role creation wizard and give it a descriptive name (e.g.,  entra_cross_account_role ).
Trust policy should look like this:
Plain text
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<ACCOUNT_B_ID>:saml-provider/IAMIdentityCenter-AccountA"
            },
            "Action": [
                "sts:AssumeRoleWithSAML",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "SAML:sub_type": "persistent"
                }
            }
        }
    ]
}

For detailed steps, see  Create a SAML 2.0 Federation IAM Role . Step 6 — Attach an Inline Policy to the IAM Role (Account B)

Add an inline policy that grants the  appstream:Stream  permission to the WorkSpaces Applications stack:
Plain text
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "appstream:Stream",
            "Resource": "arn:aws:appstream:<REGION>:<ACCOUNT_B_ID>:stack/<STACK_NAME>",
            "Condition": {
                "StringEquals": {
                    "appstream:userId": "${saml:sub}"
                }
            }
        }
    ]
}
Replace  <REGION> ,  <ACCOUNT_B_ID> , and  <STACK_NAME>  with your actual values. The stack name is case-sensitive.
For detailed steps, see  Embed an Inline Policy for the IAM Role .

Step 7 — Note the IAM Role ARN and Identity Provider ARN (Account B)

Record both ARNs — you'll need them for the attribute mapping in the next step:
  • IAM Role ARN:  arn:aws:iam::<ACCOUNT_B_ID>:role/entra_cross_account_role 
  • SAML Provider ARN:  arn:aws:iam::<ACCOUNT_B_ID>:saml-provider/IAMIdentityCenter-AccountA  

Also verify that the relay state URL in Step 2 points to the correct region and stack. Step 8 — Configure Attribute Mappings in the IAM IDC Application (Account A)

Return to Account A and open the WorkSpaces Applications SAML application in IAM Identity Center. Navigate to Actions → Edit attribute mappings and configure the following :

Important: The  Role  attribute value is a comma-separated pair of the IAM Role ARN and the SAML Provider ARN — both from Account B. There must be no spaces around the comma.
Choose Save changes.

Step 9 — Assign Users or Groups to the Application (Account A)

In the IAM Identity Center console, open the WorkSpaces Applications application and assign it to the appropriate users or groups that were provisioned via SCIM from Entra ID.

Step 10 — Test the Configuration

  1. Navigate to the IAM IDC access portal URL (e.g.,  https://d-ab67f9bf02.awsapps.com/start ).
  1. Sign in with your Microsoft Entra ID credentials.

  1. Click the Applications tab.

  1. Select the Amazon WorkSpaces Applications tile.
  1. You should be redirected to the WorkSpaces Applications stack in Account B and the streaming session should start.

Key Considerations
  •  Relay state region endpoints  — Use the recommended  euc-sso  relay state endpoints (e.g.,  https://appstream2.euc-sso.us-east-1.aws.amazon.com/saml ). These support the WorkSpaces Applications client application and allow users to sign into other AWS applications in different browser tabs without disconnecting the streaming session.
  • Subject format — The Subject NameID format must be set to  persistent . This is required for the SAML federation to work correctly with WorkSpaces Applications.
  • Stack name case sensitivity — The stack name in the relay state URL and the inline policy must match the exact case and spelling as shown in the WorkSpaces Applications console.
  • Session duration — The default session duration is 1 hour. You can adjust this in the application properties. If you don't specify the  SessionDuration  attribute, it defaults to 60 minutes.
  • Multiple stacks — If you need to provide access to multiple stacks, you can use attribute-based application entitlements. Remove the  stack  parameter from the relay state URL and set the inline policy resource to  arn:aws:appstream:<REGION>:<ACCOUNT_B_ID>:stack/* .
  • SCIM sync — Ensure that the users and groups you assign to the application in IAM IDC are properly synced from Entra ID via SCIM provisioning.

Conclusion

This cross-account pattern keeps identity management centralized in a single account while letting workload teams own their WorkSpaces Applications resources independently. The SAML trust chain — Entra ID → IAM Identity Center → IAM Identity Provider (Account B) → IAM Role (Account B) — gives you clean separation of duties without sacrificing the single sign-on experience your users expect.

References

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article