Amazon AppStream 2.0
Developer Guide

Setting Up SAML

To enable users to sign in to AppStream 2.0 by using their existing credentials, and start streaming applications, you can set up identity federation using SAML 2.0. To do this, use an IAM role and a relay state URL to configure your SAML 2.0-compliant identity provider (IdP) and enable AWS to permit your federated users to access an AppStream 2.0 stack. The IAM role grants users the permissions to access the stack. The relay state is the stack portal to which users are forwarded after successful authentication by AWS.


Complete the following prerequisites before configuring your SAML 2.0 connection.

  1. Configure your SAML-based IdP to establish a trust relationship with AWS.

    • Inside your organization's network, configure your identity store to work with a SAML-based IdP. For configuration resources for using Ping Identity, Okta, Active Directory Federation Services (AD FS) in Windows Server, Shibboleth, or Google as your SAML-based IdP, see AppStream 2.0 Integration with SAML 2.0.

    • Use your SAML-based IdP to generate and download a federation metadata document that describes your organization as an IdP. This signed XML document is used to establish the relying party trust. Save this file to a location that you can access from the IAM console later.

  2. Use the AppStream 2.0 management console to create an AppStream 2.0 stack. You need the stack name to create the IAM policy and to configure your IdP integration with AppStream 2.0, as described later in this topic.

    You can create an AppStream 2.0 stack by using the AppStream 2.0 management console, AWS CLI, or AppStream 2.0 API. For more information, see Create AppStream 2.0 Stacks and Fleets.

Step 1: Create a SAML Identity Provider in AWS IAM

First, create a SAML IdP in AWS IAM. This IdP defines your organization's IdP-to-AWS trust relationship using the metadata document generated by the IdP software in your organization. For more information, see Creating and Managing a SAML Identity Provider (AWS Management Console) in the IAM User Guide.

Step 2: Create a SAML 2.0 Federation IAM Role

Next, create a SAML 2.0 federation IAM role. This step establishes a trust relationship between IAM and your organization's IdP, which identifies your IdP as a trusted entity for federation.

To create an IAM role for the SAML IdP

  1. Open the IAM console at

  2. In the navigation pane, choose Roles, Create role.

  3. For Role type, choose SAML 2.0 federation.

  4. For SAML Provider, select the SAML IdP that you created.


    Do not choose either of the two SAML 2.0 access level methods.

  5. For Attribute, choose SAML:sub_type.

  6. For Value, type persistent. This step restricts role access to only SAML user streaming requests that include a SAML subject type assertion with a value of persistent. If the SAML:sub_type is persistent, your IdP sends the same unique value for the NameID element in all SAML requests from a particular user. For more information about the SAML:sub_type assertion, see the Uniquely Identifying Users in SAML-Based Federation section in Using SAML-Based Federation for API Access to AWS.

  7. Review your SAML 2.0 trust information, confirming the correct trusted entity and condition, and then choose Next: Permissions.

  8. On the Attach permissions policies page, choose Next: Review. You create and embed an inline policy for this role later.

  9. For Role name, type a name that helps you identify the purpose of this role. Because various entities might reference the role, you cannot edit the name of the role after it has been created.

  10. (Optional) For Role description, type a description for the new role.

  11. Review the role details and choose Create role.

Step 3: Embed an Inline Policy for the IAM Role

Next, embed an inline IAM policy for the role that you created. When you embed an inline policy, the permissions in the policy cannot be inadvertently attached to the wrong principal entity. The inline policy provides federated users with access to the AppStream 2.0 stack that you created. For information about how to embed the inline policy in JSON, see Create a Policy on the JSON Tab.

As you follow the steps in the procedure for embedding an inline policy for a user or role, note that you’ll create a policy on the JSON tab. To do this, copy and paste the following JSON policy into the JSON window and modify the resource by entering your AWS Region Code, account ID, and stack name. In the following policy, "Action": "appstream:Stream" is the action that provides your AppStream 2.0 users with permissions to connect to streaming sessions on the stack that you created.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "appstream:Stream", "Resource": "arn:aws:appstream:REGION-CODE:ACCOUNT-ID-WITHOUT-HYPHENS:stack/STACK-NAME", "Condition": { "StringEquals": { "appstream:userId": "${saml:sub}", "saml:sub_type": "persistent" } } } ] }

Choose a value for REGION-CODE that corresponds to the AWS Region where your AppStream 2.0 stack exists. Replace STACK-NAME with the name of the stack. Note that this value is case-sensitive, so the case in the stack name that you specify in this policy must match the case in the AppStream 2.0 stack name as it appears in the Stacks dashboard of the AppStream 2.0 management console.


After you copy and paste the JSON policy, you may see an error message that indicates the validation failed. Ignore the error and continue with policy creation. You may also see an error on the Review policy page that indicates the policy does not grant any permissions. Ignore this error. The JSON policy is valid and provides the needed permissions.

Step 4: Configure Your SAML-Based IdP

Next, depending on your SAML-based IdP, you may need to manually update your IdP to trust AWS as a service provider by uploading the saml-metadata.xml file at to your IdP. This step updates your IdP’s metadata. For some IdPs, the update may already be configured. If this is the case, proceed to the next step.

If this update is not already configured in your IdP, review the documentation provided by your IdP for information about how to update the metadata. Some providers give you the option to type the URL, and the IdP obtains and installs the file for you. Others require you to download the file from the URL and then provide it as a local file.

Step 5: Create Assertions for the SAML Authentication Response

Next, depending on your SAML-based IdP, you may need to configure the information that the IdP passes as SAML attributes to AWS as part of the authentication response. For some IdPs, this information may already be configured. If this is the case, proceed to the next step.

If this information is not already configured in your IdP, provide the following:

  • SAML Subject NameID – The unique identifier for the user who is signing in.


    For stacks with domain-joined fleets, the NameID value for the user must be provided in the format of "domain\username" using the sAMAccountName or "" using userPrincipalName. If you are using the sAMAccountName format, you can specify the domain by using either the NetBIOS name or the fully qualified domain name (FQDN). For more information, see Using Active Directory Domains with AppStream 2.0.

  • SAML Subject Type (with a value set to persistent) – Setting the value to persistent ensures that your IdP sends the same unique value for the NameID element in all SAML requests from a particular user. Make sure that your IAM policy includes a condition to only allow SAML requests with a SAML sub_type set to persistent, as described in Step 2: Create a SAML 2.0 Federation IAM Role.

  • Attribute element with the Name attribute set to – This element contains one or more AttributeValue elements that list the IAM role and SAML IdP to which the user is mapped by your IdP. The role and IdP are specified as a comma-delimited pair of ARNs.

  • Attribute element with the SessionDuration attribute set to (optional) – This element contains one AttributeValue element that specifies the maximum amount of time that a federated streaming session for a user can remain active before reauthentication is required. The default value is 60 minutes. For more information, see the An optional Attribute element with the SessionDuration attribute set to section in Configuring SAML Assertions for the Authentication Response.

For more information about how to configure these elements, see Configuring SAML Assertions for the Authentication Response in the IAM User Guide. For information about specific configuration requirements for your IdP, see the documentation for your IdP.

Step 6: Configure the Relay State of Your Federation

Finally, use your IdP to configure the relay state of your federation to point to the AppStream 2.0 stack relay state URL. After successful authentication by AWS, the user is directed to the AppStream 2.0 stack portal, defined as the relay state in the SAML authentication response.

The format of the relay state URL is as follows:


Construct your relay state URL from your AWS account ID, stack name, and the relay state endpoint associated with the region in which your stack is located.

Region Relay state endpoint
us-east-1 (N.Virginia)
us-west-2 (Oregon)
eu-west-1 (Ireland)
ap-northeast-1 (Tokyo)
ap-southeast-1 (Singapore)
ap-southeast-2 (Sydney)