Authentication - Best Practices for Deploying Amazon AppStream 2.0

Authentication

With AppStream 2.0, authentication can either take place outside of Amazon AppStream 2.0, or as part of the AppStream 2.0 service. Selecting how authentication will take place for your AppStream 2.0 deployment is a fundamental consideration of your design. It’s not uncommon for an organization to have multiple deployments of AppStream 2.0 for different use-cases. Each use-case can have a different authentication method.

There are three types of authentication methods for AppStream 2.0:

Determining optimized method

Amazon AppStream 2.0 is architected to be flexible to apply to most organizational design requirements. When determining the optimized method for authentication, it is a best practice to consider the objectives and purposes of those who consume the service, and the organizational policies and procedures.

Here are some examples of combining use-cases with organizational objectives.

Table 4 — Use cases with organizational objectives

Example Description Authentication
Domain joined fleet instances are required Applications installed on the AppStream image are accessible only to domain joined resources. SAML 2.0
Heavy integration with Microsoft services Organizational dependence on developing Microsoft Group Policies and backend infrastructure SAML 2.0
Existing enterprise Single Sign-on (SSO) All new services must leverage an enterprise SSO solution that has several reporting and security processes established. SAML 2.0
Smart card support for applications Smart cards (such as Private Identity Verification and common access cards) for in-session authentication to streamed applications through a smart card reader. SAML 2.0
Seasonal workforce with temporary staffing A few months out of the year, temporary workers are assigned a small set of applications that do not include internal resources to complete activities. User Pool
Limited IT Support Smaller organizations with less than 50 users and limited IT staff, looking to remove the overhead of maintaining an Identity Provider (IdP) User Pool
Independent Software Vendor (ISV) Proprietary solution built by your organization that includes user entitlement and authentication, extending AppStream 2.0 as part of your solution.* Programmatic
Technology showcase Completely ephemeral environment that showcases a proprietary technology as part of a guided tour of your solution with no requirement to store user information. Programmatic
Interactive website experience

Make your website interactive with streaming Windows applications.**

Programmatic

*Refer to Software vendors: Deliver your applications to any user device for more information.

**Refer to Embed AppStream 2.0 Streaming Sessions for more information.

If your organization has a use-case or policy that is not listed in the examples previously given, it is a best practice to forecast the desired end state of AppStream 2.0 workflow consumption to ensure the authentication solution does not conflict with it.

Configuring your identity provider

SAML 2.0

Security Assertion Markup Language (SAML) 2.0 is a common deployment option for enabling users to use AWS resources. Various third-party SAML 2.0 identity providers support AppStream 2.0. Whether your AppStream 2.0 resources are domain joined or not, SAML 2.0 IdP requires you to use IAM.

As most IdPs generate a unique metadata.xml with specific SAML attributes for each SAML application, every AppStream 2.0 stack requires a Role that has a trusted relationship with the SAML IdP and a Policy that has a single permission to appstream:Stream with conditions that match the requirements of the SAML IdP and the ARN of the AppStream 2.0 Stack.

The AppStream 2.0 administration guide provides an example configuration for single AppStream 2.0 stack design. For multiple stack deployments, refer to the optional steps for using SAML 2.0 multi-stack application catalog.

User pool

The User Pool tab in AppStream 2.0 is a valid option for small proof of concepts. As a best practice, it is best to avoid user pools for any use case and organization that uses AppStream 2.0 to deliver production applications.

One important thing to note about user pools is that users’ email addresses are case-sensitive; therefore it is a best practice to ensure users are educated on how to properly enter user credentials.

Streaming url

For deployments that call AppStream 2.0 resources from a centralized service (typically ISVs), programmatic authentication relies on an application to make programmatic calls to AWS to dynamically pass information and create an AppStream 2.0 session for its users. Use the API authentication method (commonly referred to as ‘programmatic’) when creating streaming URLs using the CreateStreamingURL operation. The user who makes the CreateStreamingURL call must be using a valid user or role with permission for appstream:CreateStreamingURL.

When creating the policy for programmatic access, it is a best practice to secure access by specifying the exact AppStream 2.0 Stack ARN in the Resources section in place of the default ‘*’. For example:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "appstream:createStreamingURL" ], "Resource": "arn:aws:appstream:us-east- 1:031421429609:stack/BestPracticesStack" } ] }
Note

You can quickly retrieve the ARNs of your AppStream 2.0 Stacks by using the describe stacks API or AWS CLI.

AppStream 2.0 instances should start as generic instances. Through information passed to it from the application, the AppStream 2.0 instance establishes the environment using session context to make things dynamic for the user.

While local GPOs can be used to specify settings at user logon, session context is a best practice when using CreateStreamingURL, and passing key attributes such as Customer ID or database connection settings, to be used in the AppStream session.

Application entitlement

AppStream 2.0 can dynamically build the application catalog that is presented to users. Application entitlements are based on SAML 2.0 attributes, or by using AppStream 2.0 Dynamic Application Framework.

Attribute-based application entitlements using SAML 2.0 is recommended in most scenarios. To manage application package delivery, Dynamic Application Framework is recommended.