AWS ClientVPN SAML-based authentication via Tools4ever HelloID

Extensive documentation exists for implementing SAML-based authentication for AWS Client VPN through IDPs like Okta and Azure AD, but if you or your customers happen to use a different IDP – documentation is hard to come by. Combine this with the fact that most AWS Managed / Professional Services teams don’t have access to a customer’s IDP – implementation often becomes tricky. In this blog I provide a step by step guide to configure your SAML application in Tools4ever’s IDP product – HelloID.

Towards the end of this article we take a look at authorization rules as implemented by AWS Client VPN. We look at how you could get this working in a scenario where you have several external entities / suppliers connecting to your network via AWS Client VPN. Providing granular access to external entities while maintaining less restrictive rules for your tech personnel supporting these entities is perhaps something you would like to implement. Authorization rules are the first port of entry for any authenticated VPN user. Network ACL’s and Security Groups determine exactly what these users can do with this access, and determine their network reach.

AWS Client VPN SAML-based implementation Okta: https://aws.amazon.com/blogs/networking-and-content-delivery/authenticate-aws-client-vpn-users-with-saml/

AWS Client VPN SAML-based implementation AzureAD: https://docs.microsoft.com/en-gb/azure/active-directory/saas-apps/aws-clientvpn-tutorial

AWS Client VPN Documentation for SAML-based authentication: https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/client-authentication.html#federated-authentication

SAML Tracer: Useful tool for SAML troubleshooting: https://chrome.google.com/webstore/detail/saml-tracer/mpdajninpobndbfcldcmbpnnbhibjmch?hl=en

Solution Overview

In the solution above, the clientVPN endpoint has been configured in the transit gateway account. This is by no means required, but is our preferred approach when configuring external connectivity to a customer’s AWS environment.

Configure Generic SAML App in HelloID

Begin by creating a self-signed certificate for use by the SAML Application:

Create a new SAML Application

General Configuration

Single Sign-On

If you don’t plan to use self-service functionality, you can disable the “Validate and use ACS request URL” option, and leave the ACS validation list blank. The only requirement in this case is the Endpoint/ACS URL, which needs to be http://127.0.0.1:35001 (note http, not https).

Post application creation tasks
Application Group Membership

Add the required groups to be used by this application.

Map required Attributes

Click “Change mappings”

Add LastName, FirstName attributes

Export / Download SAML Metadata document

Click Download metadata at the top right of the screen and save the file to your local computer. The contents of this xml file will be used to configure the identity provider in AWS IAM for the AWS ClientVPN Endpoint.

AWS Client VPN Authorization Rules

The memberOf attribute of the SAML response returns all the groups that the authenticated user is a member of. This allows us to implement granular authorization rules for each group i.e. allow all members of a certain group to access, for example, a single IP (e.g. 192.168.1.24/32), or a range of IP’s / subnet (192.168.1.0/24). AWS implements this using the longest prefix match for the destination IP (range) – which is fine if you don’t have many VPN users / groups with different/overlapping access requirements.

If a certain group has access to a specific IP / range – that range is no longer accessible to other groups, even if an authorization rule assigned to one of the other groups includes an even broader IP range.

For example:

In this scenario, Supplier2 will not have access to 192.168.1.24/32, as Supplier1 has the longest prefix match. AdminsGroup will not have access to 192.168.1.24/32 or 192.168.1.0/24

To get around this, we might simply add more authorization rules…

This will work – BUT, you can see how quickly this can become an administrative nightmare – especially for groups that need access to a broader range of IP’s/subnets – as you would effectively need to add every single IP address (or range) from the other groups for these users.

So how do we resolve this?

The solution is actually quite simple – keep the supplier group authorization rules as granular as possible i.e. maintain authorization rules as specific as possible for each supplier – even if these rules overlap.

For your admin users – simply make the admins group a member of all the supplier groups in your IDP. you would end up with something like this:

One last tip: If you host internal DNS, create authorization rules allowing all users to access those services. This allows your VPN clients to access resources on your network using host names instead of IP addresses. IMPORTANT: Be sure to only allow access to port 53 from your ClientVPN Endpoint associated subnets to your DNS servers.