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
**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
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
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.