AWS Verified Access Integration with AWS IAM Identity Center and SAML 2.0 Identity Providers

In this blog post, we will discuss how you can setup VPN-less secure access to your corporate applications if you are using Security Assertion Markup Language (SAML) based identity providers (IdPs). We will also provide guidance if you have already invested in integrating third-party IdPs with AWS IAM Identity Center (successor to AWS Single Sign-On), to centralize access management as described in the Connect to an external identity provider section in the IAM Identity Center documentation. We will be contrasting the traditional architecture patterns our customers have used to access corporate applications against the new approach using AWS Verified Access (AVA) to enable workforce mobility. Corporate applications refer to HTTP/HTTPS-based applications running in AWS, which are accessed by corporate users.

Our solutions in this post will use Amazon Verified Access, a VPN-less remote connectivity service built using AWS Zero Trust guiding principles. In addition to continuous verification of each user access request to corporate applications, AVA supports identity providers (IdPs) using the OpenID Connect (OIDC) methods for authentication and authorization. However, you may use SAML-based IDPs to manage access to your corporate applications. This blog will also walk you through how to integrate your SAML-based IDPs with IAM Identity Center, which allows you to authenticate end users with third-party IdPs and seamlessly integrate AVA with IAM Identity Center.

IAM Identity Center (successor to AWS Single Sign-On)

Before we look at how the integration works, let’s understand what IAM Identity Center is and how it works in conjunction with external IdPs. IAM Identity Center helps you simplify and centralize access management to multiple AWS accounts, AWS applications, and other SAML-enabled cloud applications. IAM Identity Center is the recommended approach for workforce authentication and authorization on AWS for organizations of any size and type. Although you can create your workforce users directly in IAM Identity Center, you may choose to use an external SAML IdP, such as Okta, to manage users, groups, and group memberships. You can integrate these external IdPs with IAM Identity Center to authenticate identities centrally from the IdPs through the SAML 2.0 standard. You can use System for Cross-domain Identity Management (SCIM) to automate the provisioning of users from your external IdP into IAM Identity Center. This enables your users to sign in to the AWS access portal with their corporate credentials and admins to manage, monitor, and review flexible permissions aligned with roles and projects in a centralized manner. This helps eliminate the administrative burden of requiring additional setup in each individual AWS account. Developers can simply sign in to the AWS Command Line Interface (AWS CLI) using their existing credentials and then benefit from automatic short-term credential generation and rotation.

Architecture patterns for accessing corporate applications without Verified Access

The following patterns help access corporate application without Verified Access.

Accessing corporate applications over private connectivity

Figure 1 shows our first pattern, where you typically access your AWS resources by utilizing AWS VPN and/or AWS Direct Connect connections between your on-premises infrastructure and AWS. In 2018, we introduced AWS Client VPN as an additional native remote access connectivity option, enabling remote/mobile users to connect to their AWS resources securely using a VPN client application. VPNs work on an implicit trust model where users connected through the VPN have permissive access to an application. SAML-based authentication and login for users is typically performed by the IdP. This leaves the functionality of the application access control (authentication and authorization) dependent on network controls, such as access rules, security groups, and VPN policies. These are typically managed by different teams (network admins, IT admins, and developers), thus increasing the complexity of security operations.

Figure 1: Accessing corporate applications over private connectivity

Accessing corporate applications over the internet

The second pattern shown in the following figure is for internet-facing corporate applications. You may have integrated your internet-facing AWS Application Load Balancer (ALB) with both AWS WAF and an OIDC provider as described in the Authenticate users using an Application Load Balancer section of the ALB documentation. If you are using SAML IdPs for corporate identities, you can access the architecture pattern in this section through the user pools supported by Amazon Cognito.

In this scenario, when users attempt to access the application behind the ALB:

(X) You authenticate users with the SAML IdP.

(Y) Amazon Cognito acts as a federation proxy and generates an OIDC token from the SAML assertion. Amazon Cognito sends the OIDC token to the ALB.

(Z) You send user claims from the ALB to the application using HTTP header x-amzn-oidc-data.

The application consumes this header to identify the authenticated users. However, device health and other security signals aren’t verified by the ALB. You also incur overhead and operations costs managing the federation proxy.

Figure 2: Accessing corporate applications over the internet

Architecture patterns comparison

Looking at both scenarios (in Figure 1 and Figure 2), you implement enterprise device management policies to make sure that devices accessing the corporate network are secure, up-to-date, and compliant with organizational policies. Both scenarios have the following challenges:

1. Adds administrative overhead for IT, network, and security admins to manage multiple policies. For example, updating policies requires multiple changes: network layer VPN policies, device management and identity policies, and, if applicable, the application layer access control policies.
2. Evaluates access once and grants the user access to all applications. There’s no continuous policy re-validation check when users access applications, which could possibly lead to a bad actor compromising the applications once being granted network access.
3. The corporate network is the center of the IT and considered a trusted boundary to enable users’ access to applications. Trustworthiness of users and devices is not evaluated while granting users’ access to applications.

Secure access to corporate applications with SAML IdPs using IAM Identity Center and AWS Verified Access

With AVA, using zero trust principles, your applications become the center of your IT universe, with access policies built around the applications and not the network.

Using AVA, you can setup zero trust access to your applications using straightforward policies and continuously validate access requests using user and device data. Remote and in-office users can connect securely to internal applications seamlessly, without needing to sign in or use a VPN.

If you are using a SAML IdP, you can setup the IdP so that it is integrated with IAM Identity Center using SAML federation. IAM Identity center is configured as an Identity Trust Provider for AVA. Users can securely access corporate applications using the Single Sign-On credentials from anywhere.

Figure 3: Corporate applications behind Verified Access for organizations using SAML IdP

The architecture outlined in Figure 3 has the following components:

(1) A SAML based IdP, for example Okta, which is leveraged for Single Sign-On.

(2) An instance of IAM Identity Center that is used for central access control of AWS accounts and AWS applications. SAML IdP is integrated with IAM Identity Center as outlined in the Supported identity providers section in the IAM Identity Center documentation.

(3) AVA integrated with IAM Identity Center as the Identity Trust Provider. Refer to the AVA User Guide that discusses the basics of AVA and how to integrate it with AWS Identity Center. To set up IAM Identity Center as a trust provider for AVA:

• Create a Verified Access instance and configure the trust providers
• Create Verified Access groups and assign group level policies

(4) An internal ALB, Network Load Balancer (NLB), or an Elastic Network Interface (ENI) fronting the corporate application configured to an AVA Endpoint.

• Create Verified Access Endpoint
• Create and assign access policies to AVA Endpoint

(5) Optional – in addition to authentication and authorization rules enforced by AVA and IAM Identity Center, you can add additional layers of defense by integrating AWS WAF with AVA to help protect web applications (HTTP/HTTPS) from application-layer threats.

(6) Optional -you can setup logging and monitoring for AVA and IAM Identity Center. Like Identity Center, after AVA evaluates each access request, it logs all access attempts. This provides centralized visibility into application access and helps you quickly respond to security incidents and audit requests.

Verified Access request authentication and authorization flow

The following figure highlights the authentication and authorization steps when a user accesses the corporate application using AVA:

Figure 4: Verified Access request authentication and authorization flow

(A) The initial request is made to the application domain hosted on an AVA endpoint. This request does not have an identity cookie.

(B) The first redirect is made to the identity provider, in this case IAM Identity Center, to collect the user identity.

(C) The browser redirects to the IAM Identity Center URL.

(D) A second redirect is made to the external IdP. The user completes the IdP sign-in process.

(E) IAM Identity Center redirects the user to the application domain to validate the identity token.

(F) The browser sends the application domain endpoint, the IAM Identity Center token, which AVA uses to set the user identity cookie.

(G) AVA redirects the user with the user identity cookie to the original URI.

(H) AVA receives the request with the user identity cookie.

(I) For each user request, AVA validates the user’s request against the Cedar policy for the application using the identity of the user.

(J) AVA proxies validated requests sent to application endpoints in your VPC.

Using AVA allows for continuous verification on each user access request. This is regardless of the number of times the user tries to access the application and not just at the initial login.

Considerations

The following considerations are relevant to the points made in this post:

• AVA currently only supports HTTP/HTTPS based traffic.
• Refer to the AVA quotas page and be aware of the HTTP headers and OIDC claim size limits.
• AVA is a Regional service. You must deploy the application in the same AWS Region that AVA is deployed.
• AVA only supports ALB, NLB, and ENI as targets for the application group.
• Currently, the following device trust providers integrate with AVA.
• Verified Access is available in these AWS Regions.

Conclusion

Customers can leverage IAM Identity Center and AVA to centralize authentication for corporate applications and the AWS resources that manage the data and infrastructure of corporate applications. This is all while using third-party SAML IdPs and still getting single-sign-on. With this architecture pattern, you can simplify connectivity and implement Zero Trust access, with continuous and contextual authentication, detailed logging, and monitoring of access requests.

For more information, refer to the following resources:

1. AWS Verified Access Request Verification Flow
2. AWS Verified Access User Guide
3. Integrating AWS Verified Access with device trust providers
4. AWS Verified Access Integration with 3^rd party Identity providers

About the authors