Setting Up SAML - Amazon AppStream 2.0

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.

Prerequisites

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, 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 an AppStream 2.0 Fleet and Stack.

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 (Amazon Web Services Management Console) in the IAM User Guide. For information about working with SAML IdPs in AWS GovCloud (US-West), see AWS Identity and Access Management in the AWS GovCloud (US) 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 https://console.aws.amazon.com/iam/.

  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.

    Important

    Do not choose either of the two SAML 2.0 access methods (Allow programmatic access only or Allow programmatic and Amazon Web Services Management Console access).

  5. For Attribute, choose SAML:sub_type.

  6. For Value, enter persistent. This value restricts role access to 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: Tags.

  9. (Optional) Enter a key and value for each tag that you want to add. For more information, see Tagging IAM Users and Roles.

  10. When you're done, choose Next: Review. Later, you'll create and embed an inline policy for this role.

  11. For Role name, enter a name that identifies the purpose of this role. Because multiple entities might reference the role, you can't edit the role's name once it is created.

  12. (Optional) For Role description, enter a description for the new role.

  13. Review the role details and choose Create role.

  14. (Optional) If you plan to use attribute-based application entitlements using a third-party SAML 2.0 identity provider, you must add the sts:TagSession permission to your new IAM role's trust policy. For more information, see Attribute-Based Application Entitlements Using a Third-Party SAML 2.0 Identity Provider and Passing session tags in AWS STS.

    In your new IAM role's details, choose the Trust relationships tab, and then choose Edit trust relationship. The Edit Trust Relationship policy editor starts. Add the sts:TagSession permission, as follows:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:saml-provider/IDENTITY-PROVIDER" }, "Action": [ "sts:AssumeRoleWithSAML", "sts:TagSession" ], "Condition": { "StringEquals": { "SAML:sub_type": "persistent" } } } ] }

    Replace IDENTITY-PROVIDER with the name of the SAML IdP you created in Step 1. Then choose Update Trust Policy.

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 that policy can't be accidentally attached to the wrong principal entity. The inline policy provides federated users with access to the AppStream 2.0 stack that you created.

  1. In the details for the IAM role that you created, choose the Permissions tab, and then choose Add inline policy. The Create policy wizard starts.

  2. In Create policy, choose the JSON tab.

  3. Copy and paste the following JSON policy into the JSON window. Then, 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}" } } } ] }

    Replace REGION-CODE with the AWS Region where your AppStream 2.0 stack exists. Replace STACK-NAME with the name of the stack. STACK-NAME is case-sensitive, and must match the exact case and spelling as the stack name shown in the the Stacks dashboard of the AppStream 2.0 management console.

    For resources in AWS GovCloud (US-West), use the following format for the ARN:

    arn:aws-us-gov:appstream:REGION-CODE:ACCOUNT-ID-WITHOUT-HYPHENS:stack/STACK-NAME

  4. (Optional) If you are planning to use attribute-based application entitlements using a third-party SAML 2.0 identity provider with SAML 2.0 Multi-stack Application Catalogs, the Resource in your IAM role inline policy must be "Resource": "arn:aws:appstream:REGION-CODE:ACCOUNT-ID-WITHOUT-HYPHENS:stack/*" to allow application entitlements to control streaming access to stacks. To enforce additional protection on a stack resource, you can add an explicit deny in the policy. For more information, see Attribute-Based Application Entitlements Using a Third-Party SAML 2.0 Identity Provider and Policy evaluation logic.

  5. When you're done, choose Review policy. The Policy Validator reports any syntax errors.

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 https://signin.aws.amazon.com/static/saml-metadata.xml 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, you may need to configure the information that your IdP sends to AWS as SAML attributes in its authentication response. Depending on your IdP, this information may already be pre-configured. If this is the case, skip this step and continue to Step 6,

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.

    Note

    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 "username@domain.com" 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 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 https://aws.amazon.com/SAML/Attributes/Role – 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 Name attribute set to https://aws.amazon.com/SAML/Attributes/RoleSessionName – This element contains one AttributeValue element that provides an identifier for the AWS temporary credentials that are issued for SSO. The value in the AttributeValue element must be between 2 and 64 characters long, can contain only alphanumeric characters, underscores, and the following characters: + (plus sign), = (equals sign), , (comma), . (period), @ (at symbol), and - (hyphen). It cannot contain spaces. The value is typically a user ID (bobsmith) or an email address (bobsmith@example.com). It should not be a value that includes a space, such as a user's display name (Bob Smith).

  • Attribute element with the Name attribute set to https://aws.amazon.com/SAML/Attributes/PrincipalTag:SessionContext (optional) – This element contains one AttributeValue element that provides parameters that can be used to pass session context parameters to your streaming applications. For more information, see Session Context.

  • Attribute element with the SessionDuration attribute set to https://aws.amazon.com/SAML/Attributes/SessionDuration (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 https://aws.amazon.com/SAML/Attributes/SessionDuration section in Configuring SAML Assertions for the Authentication Response.

    Note

    Although SessionDuration is an optional attribute, we recommend that you include it in the SAML response. If you do not specify this attribute, the session duration is set to a default value of 60 minutes.

    If your users access their streaming applications in AppStream 2.0 by using the AppStream 2.0 client, their sessions are disconnected after their session duration expires. If your users access their streaming applications in AppStream 2.0 by using a web browser, after the users' session duration expires and they refresh their browser page, their sessions are disconnected.

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:

https://relay-state-region-endpoint?stack=stackname&accountId=aws-account-id-without-hyphens

Construct your relay state URL from your Amazon Web Services account ID, stack name, and the relay state endpoint associated with the Region in which your stack is located.

Optionally, you can specify the name of the application that you want to launch automatically. To find the application name, select the image in the AppStream 2.0 console, choose the Applications tab, and note the name that displays in the Application Name column. Alternatively, if you haven't yet created the image, connect to the image builder where you installed the application, and open Image Assistant. The names of applications display in the Add Apps tab.

If your fleet is enabled for the Desktop stream view, you can also choose to launch directly to the operating system desktop. To do so, specify Desktop at end of the relay state URL, after &app=.

With attribute-based application entitlements using a third-party SAML 2.0 identity provider, you can enable access to multiple stacks from a single relay state URL. Remove the stack and app (if present) parameters from the relay state URL, as follows:

https://relay-state-region-endpoint?accountId=aws-account-id-without-hyphens

When users federate to the AppStream 2.0 application catalog, they will be presented with all of the stacks where application entitlements have matched one or more applications to the user for the account ID and relay state endpoint associated with the Region in which your stacks are located. When a user selects a catalog, application entitlements will only display the applications the user is entitled to.

For more information, see Attribute-Based Application Entitlements Using a Third-Party SAML 2.0 Identity Provider.

The following table lists the relay state endpoints for the Regions where AppStream 2.0 is available. If you want your users to stream using a FIPS-compliant connection, you must use a FIPS-compliant endpoint. For more information about FIPS endpoints, see Protecting Data in Transit with FIPS Endpoints.

Region Relay state endpoint
US East (N. Virginia)

https://appstream2.us-east-1.aws.amazon.com/saml

(FIPS) https://appstream2-fips.us-east-1.aws.amazon.com/saml

US West (Oregon)

https://appstream2.us-west-2.aws.amazon.com/saml

(FIPS) https://appstream2-fips.us-west-2.aws.amazon.com/saml

Asia Pacific (Mumbai) https://appstream2.ap-south-1.aws.amazon.com/saml
Asia Pacific (Seoul) https://appstream2.ap-northeast-2.aws.amazon.com/saml
Asia Pacific (Singapore) https://appstream2.ap-southeast-1.aws.amazon.com/saml
Asia Pacific (Sydney) https://appstream2.ap-southeast-2.aws.amazon.com/saml
Asia Pacific (Tokyo) https://appstream2.ap-northeast-1.aws.amazon.com/saml

Canada (Central)

https://appstream2.ca-central-1.aws.amazon.com/saml
Europe (Frankfurt) https://appstream2.eu-central-1.aws.amazon.com/saml
Europe (Ireland) https://appstream2.eu-west-1.aws.amazon.com/saml
Europe (London) https://appstream2.eu-west-2.aws.amazon.com/saml
AWS GovCloud (US-West)

https://appstream2.us-gov-west-1.amazonaws-us-gov.com/saml

(FIPS) https://appstream2-fips.us-gov-west-1.amazonaws-us-gov.com/saml

Note

For more information about using AppStream 2.0 in AWS GovCloud (US-West), see Amazon AppStream 2.0 in the AWS GovCloud (US) User Guide.