The AWS Client VPN Federated Authentication Missing Example

Integrating AWS Client VPN with AWS Single-Sign-On (SSO).

The Feature

Around mid-May 2020, Amazon released support for federated authentication using SAML 2.0 for AWS Client VPN.

AWS Client VPN is a managed, scalable virtual private network service that enables users to securely access AWS resources and on-premises networks. Federated Authentication makes it easy to integrate AWS Client VPN user authentication and authorization with a centralized, SAML based Identity Provider (IdP).

— AWS — AWS Client VPN now supports Federated Authentication via SAML 2.0

Previously, Amazon only supported active directory (user-based) and mutual authentication (certificate-based). Without active directory, one was required to use mutual authentication and so deal with managing user client certificates. This was a hassle.

Amazon currently provides a singular walk-through of integrating with a SAML 2.0 based Identity Provider (IdP), specifically with Okta: Authenticate AWS Client VPN users with SAML.

For anything but Okta, Amazon provides the following guidance:

To create a SAML-based app using an IdP that’s not listed in the preceding table, use the following information to configure the AWS Client VPN service provider information.
- Assertion Consumer Service (ACS) URL: http://127.0.0.1:35001
- Audience URI: urn:amazon:webservices:clientvpn
The following attributes are required.
- NameID The email address of the user.
- FirstName The first name of the user.
- LastName The last name of the user.
- memberOf The group or groups that the user belongs to.

— AWS — Authentication

The problem is that following this guidance requires one to have a good understanding of SAML 2.0 and, even then, requires some trial and error. This is particularly frustrating when one is trying to integrate with Amazon’s own SSO offering; AWS Single Sign-On (SSO).

Note: I ended up reverse-engineering the Okta example’s SAML 2.0 assertion to fill in some missing details in their guidance. The Google Chrome extension, SAML-tracer, was extremely helpful in this regard.

Integrating with AWS Single-Sign-On

The basic integration steps to configure AWS Single-Sign-On are mostly provided by Amazon: Custom SAML 2.0 Applications.

Note: This assumes that one already has enabled AWS Single-Sign-On. In my case, it was enabled as part of an AWS Control Tower installation.

Here we use the first bit of Amazon’s guidance to provide the Application ACS URL and Application SAML audience values.

- Assertion Consumer Service (ACS) URL: http://127.0.0.1:35001
- Audience URI: urn:amazon:webservices:clientvpn

— AWS — Authentication

But there are two missing steps that one must perform to be successful. First, one must assign the application to a user or group (fairly obvious).

Second, one must update the SAML 2.0 Assertion Attributes per the Amazon guidance (less obvious):

Points to observe:

• The NameID (the email address of the user) in the Amazon guidance translates to mapping the Subject to ${user:email} with the emailAddress format
• We also include the FirstName, memberOf, and LastName SAML 2.0 Assertion Attributes per the Amazon guidance; adding in the undocumented unspecified format. Also unfortunate is that Amazon’s documentation on this activity (Attribute Mappings) is both inaccurate and incomplete. The proper mapping for FirstName is ${user:givenName} and one can map memberOf to the undocumented ${user:groups}
• These correct SSO Attributes, however, are documented in RFC 7643 as described in another Amazon document: Supported User and Group Attributes

The integration steps for AWS Client VPN are accurately and fully documented in Single sign-on (SAML 2.0-based federated authentication) in Authentication.

Another Bit of Trickiness

One AWS Client VPN feature is the ability to authorize user’s access to specific networks based on SSO group membership.

To restrict access to specific clients, choose “allow access” to users in a specific access group, and then for Access group ID, enter the ID for the group to grant access to. For example, the security identifier (SID) of an Active Directory group, or the ID/name of a group defined in a SAML-based identity provider (IdP).

— AWS — Authorization rules

The problematic thing here is that AWS SSO does not show group IDs in the UI but if you are observant, you will notice a string of characters at the end of a Group screen’s URL.

As you guessed, this is the Group’s id that we need to use.

Note: SAML-tracer was particularly helpful here.

Conclusion

In the end, integrating AWS Client VPN with AWS Single-Sign-On (SSO) is fairly simple; but you need to know a couple of missing details to get started here. Thanks for reading this article, I hope you found it helpful.