AWS ClientVPN SAML-based authentication via Tools4ever HelloID

10 Aug, 2023
Xebia Background Header Wave

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:

AWS Client VPN SAML-based implementation AzureAD:

AWS Client VPN Documentation for SAML-based authentication:

SAML Tracer: Useful tool for SAML troubleshooting:

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 (note http, not https).


Name ID formatemailaddress
Endpoint/ACS URLhttp://
Validate and use ACS Request URLEnabled
ACS Validation listhttp://
Sign Assertion                     Enabled
Sign ResponseEnabled
X509 CertificateSelect self-signed certificate created in step 1
Overwrite AudienceEnabled
Extra Audiencesurn:amazon:webservices:clientvpn
Send Group membership attributeEnabled
Group membership attribute namememberOf (case sensitive)


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., or a range of IP’s / subnet ( 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, as Supplier1 has the longest prefix match. AdminsGroup will not have access to or

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.

Sander de Reus
As an AWS Cloud Engineer with a passion for all things IT and a history of tinkering since the days of the ZX Spectrum, I bring a unique blend of technical expertise and a lifelong curiosity for technology.

Get in touch with us to learn more about the subject and related solutions

Explore related posts