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

Settings

Certificates

Create Self-Signed Certificate

Create a new SAML Application

Applications Applications Open application catalog Generic SAML

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)

Name ID format: emailaddress Endpoint/ACS URL: http://127.0.0.1:35001 Validate and use ACS Request URL: Enabled ACS Validation list : http://127.0.0.1:35001 https://self-service.clientvpn.amazonaws.com/api/auth/sso/saml Binding : HTTP-Redirect Sign Assertion: Enabled Sign Response: Enabled X509 Certificate: Select self-signed certificate created in step 1 Overwrite Audience: Enabled Extra Audiences: urn:amazon:webservices:clientvpn Send Group membership attribute: Enabled Group membership attribute name: memberOf (case sensitive)

Post application creation tasks Application Group Membership

Applications Applications [application created above] Groups

Add the required groups to be used by this application.

Map required Attributes

Directory Mapping sets Mapping for [application created above]

Click “Change mappings”

Add LastName, FirstName attributes

Export / Download SAML Metadata document

Applications Applications [application created above]

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:

Group	Whitelisted IP(s)
Supplier1	192.168.1.24/32
Supplier2	192.168.1.0/24
AdminsGroup	192.168.0.0/16

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…

Group	Whitelisted IP(s)
Supplier1	192.168.1.24/32
Supplier2	192.168.1.24/32 192.168.1.0/24
AdminsGroup	192.168.1.24/32 192.168.1.0/24 192.168.0.0/16

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:

Group	Member(s)
Supplier1	User1 User2 AdminsGroup
Supplier2	User3 User4 AdminsGroup
AdminsGroup	Admin1 Admin2

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.