Directory architecture considerations for Amazon AppStream 2.0 Fleets for ISVs

Amazon AppStream 2.0 is used by ISVs to SaaSify Win32 applications and provide a new way of delivering functionality to customers who do not want to install, maintain and secure an application. Active Directory is an identity, authentication, configuration and management technology used in Windows environments since the release of Windows Server 2000. Enterprises typically use Active Directory and SAML authentication, however, ISVs may have simpler requirements that provide optimization options. Many organizations are moving away from the heavy lifting associated with AD, however, there are many integrations, particularly with authentication, that make AD avoidance challenging.

Active Directory joined Fleets requires a SAML 2.0 authentication which can be provided by a third party e.g. Okta, or a self hosted option such as ADFS or Simple SAML. A method of provisioning users into AD with a matching parameter to the SAML 2.0 provider is required.
AD joined Fleets will present another authentication prompt. Certificate-Based Authentication can be used to seamlessly use the initial SAML 2.0 token and bypass the AD login. AD requires administration, securing and, for an ISV, another identity store to maintain. Identities in the SAML provider need to match AD, often with a synchronization tool. With an Enterprise, users come from just one store, however, and ISV will have multiple customers, each with their own identity store.

Applications with functionality that requires an SMB File share, SQL Server Integrated Authentication and other AD integrated authentication services will benefit due to the following:

Standalone AppStream 2.0 Fleets can be authenticated to using a SAML 2.0 provider, however, many ISVs embed AppStream 2.0 into their website using a streaming URL. The benefit is that customers access a branded portal that contains other functionality as well as AppStream 2.0 applications. Users authenticate to the portal and the username is embedded in the streaming URL generated by an API. The username can be retrieved by AppStream 2.0 session scripts from metadata. The retrieved username can be further leveraged to dynamically create authentication tokens by securely leveraging other AWS services.

Active Directory is a mature service in GA since 2000, however, it requires administration, maintenance, securing and monitoring. AWS Managed Microsoft Active Directory is a managed service available for AppStream 2.0 and takes away most of the heavy lifting from the customer, however, AD is not built for automation from the ground up. Organizations are moving to agile ways of working and development including the use of Dev Ops and automated pipelines. AD does not naturally fit into a modern IT Strategy and is on the path to deprecation for many organizations.

The two main methods to authenticating to services without AD are:

Amazon AppStream 2.0 Fleets can assume an IAM Role which provides access to AWS Services that can be accessed using a role e.g. S3, Dynamo DB, Secret Store etc.
A common question is how to retrieve user and authentication information when everyone is logged into Windows as the local Photon User. Streaming URLs have a username parameter and SAML 2.0 authenticated fleets have a username variable that is passed through to the user session and can be pulled programmatically.
IAM Roles provide a way for the fleet to identify itself, however, authentication is usually required to identity a user. To generate per user tokens, Amazon AppStream 2.0 can use a combination of Amazon API Gateway, AWS Lambda, Amazon Dynamo DB and AWS Secrets Manager to pull information and passwords for further use. The information can be used to authenticate to SMB file shares, SQL Server, Oracle on RDS and other services. To further enforce security, the Lambda function can verify the username on the AppStream 2.0 session by using the describe-sessions API.

The decision to use AD hinges on whether the benefits of a familiar portal and full API driven automation is more than the amount of engineering required to ensure a secure seamless integration with required services. Removing AD improves security and reduces complexity, however this needs to be balanced with the amount of re-engineering required and other complexity introduced as part of the solution.