AWS Workspaces Overview — Part-2

Welcome to Part 2 of blog series about AWS WorkSpaces! If you missed Part 1, you can find it here. In this blog post, I’ll walk you through the architecture of connecting AWS WorkSpaces with Azure Active Directory (AD) using a technology called SAML 2.0. I’ll explain how this connection works and show you some practical situations where it can be super useful.

An important point to highlight: As of the date of this blog post, it’s crucial to note that the SAML 2.0 integration for AWS Workspaces does not offer Single Sign-On (SSO) capabilities. It’s somewhat disappointing that AWS’s official documentation doesn’t explicitly mention this limitation.

This feature was introduced relatively recently, in late 2022. While SSO may potentially be in the pipeline for future updates, it’s important to emphasize that, as of now, it is not available with SAML 2.0 integration. However, if SSO is a requirement, it’s worth exploring certificate-based authentication, although this topic falls outside the scope of this blog post.

Introduction to SAML

SAML is an acronym used to describe the Security Assertion Markup Language (SAML). Its primary role in online security is that it enables you to access multiple web applications using one set of login credentials. It works by passing authentication information in a particular format between two parties, usually an identity provider (idP) and a web application.

In Below diagram, where Azure AD is identity provider and a web app is a service provider.

Overview SAML

Prerequisites for SAML for Workspaces

Before we start configuring SAML 2.0 for AWS work spaces, below are some of the prerequisites/checks needs to be done.

1. Check if SAML 2.0 is supported in the region where your workspaces are deployed here.
2. SAML 2.0 authentication will function with WorkSpaces launched using Simple AD, but this isn’t recommended as Simple AD doesn’t integrate with SAML 2.0 IdPs.
3. SAML 2.0 authentication is supported on the following WorkSpaces clients.

Windows client application version 5.1.0.3029 or later

macOS client version 5.x or later

4. Create or register a directory for WorkSpaces by using the WorkSpaces management console. Following directory types are supported:

AD Connector

AWS Managed Microsoft AD

SAML 2.0 for Workspaces Architecture

SAML 2.0 with workspace to Azure AD

In this architectural setup, a trust relationship is established using SAML between Azure Active Directory (Azure AD) and the AWS Identity and Access Management (IAM) SAML provider within an AWS Workspaces account. It’s important to note that cross-account SAML trust is not supported in this configuration.

To implement this, an IAM role is created, and the previously established IAM SAML provider is granted a trusted relationship with this role. Additionally, an IAM policy is created, specifying the necessary permissions, particularly focusing on actions related to workspace streaming. This policy utilizes the SAML attribute “saml:username” as a variable to define access to workspace directory resources.

Full implementation steps can be found in below link

WorkSpaces Integration with SAML 2.0

User Sign in Process

1. User Registration: The user registers their Workspace Directory ID in the Workspace Client.
2. Sign-In Request: Upon registration, the user is presented with a “Sign-In” button (without visible username and password fields).
3. Azure AD Authentication: When the user clicks the “Sign-In” button, they are redirected to Azure Active Directory (Azure AD) via a web browser.
4. User Authentication: The user authenticates with their Azure AD credentials, which may include Multi-Factor Authentication (MFA). During this step, Azure AD issues a SAML token.
5. SAML Token Validation: The SAML token issued by Azure AD is validated by AWS SAML Provider to ensure the user’s identity. The user must exist in both the Workspace Directory and Azure AD.
6. Successful Authentication: After successful authentication, the user is redirected back to the Workspace Client.
7. Workspace Client Login: In the Workspace Client, the user is presented with a login screen that includes a pre-filled username and an empty password field.
8. Password Entry: The user enters their password in the empty password field.
9. Log In: The user clicks the “Sign In” button to complete the sign in process.
10. Access to Workspace: Upon successful password entry, the user is logged into the workspace.

Use Cases

Since this solution does not offer single sign on, limited use cases.

1. It enables centralized user administration through Azure AD or another supported Identity Provider (IDP), ensuring compliance with organizational policies.
2. It allows for Multi-Factor Authentication (MFA) implementation for Workspaces without the need to configure radius servers.
3. Points #1 and #2 can be accomplished without requiring network connectivity to an on-premises datacenter.

Conclusion

In conclusion, SAML 2.0 for AWS Workspaces proves to be highly beneficial for organizations running AWS workloads without network connectivity to a corporate Active Directory. It successfully ensures Multi-Factor Authentication (MFA) compliance without the need for radius instances or integration with on-premises Active Directory. It’s worth noting that there is a promising outlook for AWS to potentially offer Single Sign-On (SSO) functionality with this feature in the near future.