Desktop and Application Streaming

Create a Single Identity Provider for all your Amazon AppStream 2.0 Stacks with Azure AD

Customers use Amazon AppStream 2.0 to centrally manage applications and stream them to their end users. Organizations have multiple stacks associated with different fleets to separate workloads based on underlying resources, applications, or different user permissions. Administrators want a way to manage permissions for multiple stacks without having to create an IAM identity provider for each one.

This blog post shows you how to specify the relay state in a linked application in Azure Active Directory (Azure AD). This allows the administrator to create a single IAM identity provider and manage many AppStream 2.0 stacks at scale.

Time to read 5 minutes
Time to complete 30 minutes
Cost to complete (estimated) $0
Learning level Advanced (300)
Services used Amazon AppStream 2.0, AWS Identity and Access Management (IAM)

Overview of Solution

To enable users to sign into AppStream 2.0 by using their existing credentials, and start streaming applications, you can set up identity federation using SAML 2.0. You configure an IAM role and a relay state URL in your SAML 2.0-compliant identity provider (IdP) and enable AWS to permit your federated users’ access to an AppStream 2.0 stack.

In the Azure AD and Amazon AppStream 2.0 blog, an enterprise application was created for the users to access the AppStream 2.0 Stack. For each additional stack you create, you would repeat the steps to create an additional IAM Identity Provider and enterprise application.

Customers with many AppStream 2.0 stacks want a scalable way to manage the permissions of these stacks, without having to create an IAM Identity Provider for each stack. Some IdP providers, like Azure Active Directory Single Sign-On for Enterprise Apps, use different Federation Metadata for each application. This requires an administrator to create an IAM Identity Provider for each AppStream 2.0 Stack. This can be hard to manage and troubleshoot at scale.

In this blog, we show you how to configure AWS Identity and Access Management and Azure AD to federate into multiple AppStream 2.0 Stacks. We create a single AWS Identity Provider and Role, while maintaining least privilege.

Walkthrough

This walkthrough allows you to configure Azure AD to add a principal tag as a SAML attribute to the SAML assertion, based on a user’s group membership.

Prerequisites:

Step 1: Modify the Enterprise Application

In the Azure AD and Amazon AppStream 2.0 blog, an enterprise application was created for the users to access the AppStream 2.0 Stack. We need to modify this application so we can use it for multiple AppStream 2.0 Stacks.

  1. Open the Azure AD Console and navigate to the Enterprise Application for AppStream 2.0.
  2. Under Manage, choose Single sign-on.
  3. In the Basic SAML Configuration section choose Edit
  4. Remove the Relay State URL
  5. Under manage, choose Properties. Copy the User access URL without the tenantId. We will need to save this for a later step. An example is below:
    1. https://myapps.microsoft.com/signin/Test%20stack/00000000-0000-0000-0000-000000000000
  6. Under manage, choose Properties. Under Visible to users? Choose No

Step 2: Create a new Enterprise Application for each Stack

For each AppStream 2.0 Stack we want the users to have access to, we need to create a new Enterprise Application that includes the relay state to the appropriate stack.

  1. Open the Azure AD Console and navigate to the Enterprise Application for AppStream 2.0.
  2. Choose New application
  3. Choose Create your own application
  4. Enter a name for your application and choose Integrate any other application you don’t find in the gallery (Non-gallery)
  5. Choose
  6. The application opens. Choose Single sign-on
  7. Choose Linked.
  8. In the Sign on URL enter the URL to your enterprise application you edited in Step 1, followed by ?RelayState= and the URL-encoded relay state. An example is below:
    1. https://myapps.microsoft.com/signin/ Test%20stack/00000000-0000-0000-0000-000000000000?RelayState=https%3A%2F%2Fappstream2.us-east-1.aws.amazon.com%2Fsaml%3Fstack%3DMy-Stack%26accountId%3D012345678910
  9. To assign users to the new application, choose Users and groups. Select an Active Directory group that corresponds to the users you want to grant access to.

Step 3: Update the IAM Policy

Since multiple users accessing different stacks will assume the same role, we need to update the attached IAM policy to include multiple stacks.

  1. In the Identity and Access Management (IAM) Console, choose Policies
  2. Select the policy you created for the AppStream 2.0 role that federated users assume.
  3. Choose Edit policy
  4. Choose the JSON tab and update the following: 
    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "appstream:Stream",
            "Resource": "arn:aws:appstream:<region_code>:<account_id>:stack/<stack_name_1>",
            "Condition": {
                "StringEquals": {
                    "appstream:userId": "${saml:sub}",
                    "aws:PrincipalTag/<AD_group_1>": "true"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "appstream:Stream",
            "Resource": "arn:aws:appstream:<region_code>:<account_id>:stack/<stack_name_2>",
            "Condition": {
                "StringEquals": {
                    "appstream:userId": "${saml:sub}",
                    "aws:PrincipalTag/<AD_group_2>": "true"
                }
            }
        }
    ]
}


  5. Change <region_code> to the Region AppStream 2.0 is deployed.
  6. Change <account_id> to your AWS Account ID.
  7. Change <stack_name_1> and <stack_name_2> to the name of the AppStream 2.0 Stacks associated to the <AD_group_1> and <AD_group_2>
    1. For example, if you have a Stack called Desktop-Stack, and an AD group called DesktopStack, enter:
      1. <stack_name_1> as Desktop-Stack
      2. <AD_group_1> as DesktopStack
  8. Choose Review Policy
  9. Choose Save changes

Step 4: Update the IAM role

In IAM, we need to update the trust policy on the IAM role for your AppStream 2.0 users to assume. All AppStream 2.0 users will assume this role to simplify permissions.

  1. In the IAM AWS Console, Choose Roles
  2. Select the role you created for your AppStream 2.0 users to assume.
  3. Choose Trust relationships, Edit trust relationship.
  4. Update the Action to allow sts:TagSession
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::012345678910:saml-provider/<saml_provider_name>"
      },
      "Action": [
        "sts:AssumeRoleWithSAML",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }
  ]
}

Step 5: Update Azure AD Enterprise Application Claims

Now that we have updated the role to allow session tags and the IAM policy to use them as a condition, we need to add them into the SAML assertion. The Condition element lets you specify conditions for when a policy is in effect. In our case, when a user will have access to the AppStream 2.0 stack that you created. In this step, we add a claim to the SAML assertion with the group name as a principal tag if the user is a member of that group.

  1. Open the Azure AD Console and navigate to the Enterprise Application for AppStream 2.0. You should choose the enterprise application that represents the SAML 2.0 federation, not the linked app.
  2. Under manage, choose Single sign-on.
  3. Under Attributes & Claims, choose Edit.
  4. Choose Add new claim
  5. Enter the following:
    1. Name: PrincipalTag:<AD_group_1>
    2. Namespace: https://aws.amazon.com/SAML/Attributes
    3. Claim Conditions:
      1. User type: Members
      2. Scoped Groups: <AD_group_1>
      3. Source: Transformation
      4. Value: ToLowercase (“true”)
  1. Repeat this step for each stack you have a condition for in your IAM Policy.

Step 6: Test user access

Add a test user to the groups that correspond to the AppStream 2.0 stacks they should access. Remember that all users need access to the enterprise application for SAML, but it can be hidden from the users. Each enterprise application in linked mode should have the corresponding Active Directory group.

You can verify the SAML assertion and the SAML Attributes using a SAML Decoder, or a browser extension.

In my example I have two Active Directory Groups, DesktopStack and CADStack. In the assertion, you can see the two attributes that are added.

<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:CADStack">
 <AttributeValue>true</AttributeValue> 
</Attribute> 
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:DesktopStack">
 <AttributeValue>true</AttributeValue> 
</Attribute>

Conclusion

In this blog we showed you how to specify the relay state in a linked application in Azure Active Directory (Azure AD). You can use a single identity provider to simplify the management of AppStream 2.0 stacks at scale. This allows administrators to specify the relay state URL in the Azure AD enterprise application in linked mode and utilize the same IAM policy and role. The Conditions element in the IAM Policy only allows the user to stream the AppStream 2.0 stack if the matching claim is in the SAML assertion.

Amazon AppStream 2.0 is a fully managed nonpersistent application and desktop streaming service. You can centrally manage your desktop applications on AppStream 2.0 and securely deliver them to any computer. You can try sample applications at no cost.