In AWS, a Client VPN Endpoint is a managed, serverless cloud VPN service that enables users to securely access resources within an AWS VPC (Virtual Private Cloud). When creating this resource, AWS forces you to choose an Authentication method. There are two options:
- Mutual Authentication: This method relies entirely on AWS Certificate Manager (ACM) certificates for authentication. This means managing an ACM certificate for each person who needs access to the private networks.
- Federated Authentication with Security Assertion Markup Language 2.0 (SAML 2.0): The identity check will be done by a centralized Identity Provider, and the users will log in with their centralized credentials.
As companies grow, the need for centralized authentication increases. Imagine managing a Slack account, AWS organization, GitHub for the source code, Google Workspace for email, and many smaller regional platforms. When a lot of systems are in use, companies want to secure their assets, but also simplify the authentication process for their employees by using a central Identity Provider for all corporate applications.
Then comes the question of which system will be best to use as an identity provider (IdP). AWS has Identity Center. In it, you can configure applications, and then, with the provided metadata file, you can create an Identity Provider. However, this is a solution fundamentally designed around the AWS ecosystem. Third-party enterprise IdPs like Okta offer a much more robust, universal solution.
Okta is an identity and access management (IAM) platform built to secure user authentication across all of your corporate applications and enable developers to build identity controls into applications, websites, web services, and devices. As long as a system supports open standards like SAML 2.0 or OIDC, Okta can act as its Identity Provider.
In this blog post, we will walk through the steps for integrating Okta with the AWS Client VPN Endpoint service to create a seamless, secure remote access solution.
Prerequisite: being familiar with the Client VPN Endpoint solution.
Using Okta as IdP for the AWS Client VPN
Let’s start by creating an account in Okta. You will see a dashboard like this:
In the upper left corner, click on the tweaks button, and you will see the Administrator Console.
There, you can click on the ‘Browse App Catalog’ button and, in the search bar, type ‘AWS ClientVPN’. Choose the first option that appears. It will lead you to the application page, where you can see some information about it and click on ‘Add integration’.
For the general settings, give a name to the application and tick the box that says ‘Do not display application icon to users’. This setting makes sure that users won’t see an ‘AWS ClientVPN’ tile in their dashboard. It will be hidden from them.
After creating the application, go to the Sign-On tab and click Edit. You will be able to see and edit the SAML configurations.
Change the MemberOf setting. You should choose Matches regex from the drop-down menu and type in .*.
Save this configuration and copy the generated metadata URL. Paste it into a Chrome browser and save it locally as a file. You will need this metadata file to create an Identity provider in your AWS account in the IAM console (In the same account where you created your Client VPN Endpoint).
The Identity Provider’s ARN is required to configure AWS Client VPN.
Next, you can create users and groups in Okta. For example, you can create 3 groups – ‘dev’, ‘stage’, and ‘prod’, and add there the users that need access to the respective environment.
Return to your AWS ClientVPN Application that you already created and go to the Assignments tab. Assign all the Okta groups that you created for access to the Client VPN.
When you create the Client VPN Endpoint, and after you associate the subnets that you want to connect to, you have an option to configure Authorization rules. Here, you can specify which group has access to which network. When you are using AWS Identity Center for authentication, the Group ID setting in the Client VPN should be the ID of the group. Unlike that, when using Okta, the Group ID should be the name of the respective group. In our case: ‘dev’, ‘stage’ and ‘prod’. You can add a user only to the dev and stage Okta groups, and they will have access only to the dev and stage networks.
Now, when an OpenVPN client attempts to connect to the AWS Client VPN Endpoint, the request is sent to the configured Identity Provider. If the user passes authentication, the Client VPN Endpoint accepts the cryptographic signature returned by the Identity Provider and allows them access.
Create a Self-Service Portal in Okta
The authentication to your Client VPN is already handled by Okta. But when you are adding new users, they will have to receive the ovpn client configuration that can be downloaded from the AWS Console when you go to the configuration for your Client VPN Endpoint.
You can spare your users the clicking in AWS and create a self-service portal in Okta so they can click the tile on their dashboard and be taken directly to the page where they can download the Client VPN software for their operating system and the client configuration file.
In the Okta Console, go to Applications > Applications and click Create App Integration. Choose SAML 2.0 and click ‘Next’.
Give a name to the self-service application and again tick the box that says: ‘Do not display application icon to users’. Later, we will create a tile that will be visible to the users, and when they click on it, they will be redirected to the Client VPN portal where they will be able to download the VPN configuration.
In the Configure SAML section, use the following specific settings:
- Single Sign-On URL (ACS URL): https://self-service.clientvpn.amazonaws.com/api/auth/sso/saml
- Audience URI (SP Entity ID): urn:amazon:webservices:clientvpn
- Name ID Format: Persistent or EmailAddress
After you fill those in, click ‘Next’. Then, on the next page, don’t change anything and click ‘Finish’.
Similarly to the AWS ClientVPN application, assign this application to your already created dev, stage, and prod groups.
Then, copy the Metadata URL and save the metadata file locally. Create another IAM Identity Provider in your AWS Account (where you have created your Client VPN Endpoint). Use the new metadata that you just saved.
The ARN of this Identity Provider will be needed for the configuration of the Client VPN. For example, if you are using Terraform, you should specify the following block in your aws_ec2_client_vpn_endpoint resource:
authentication_options {
type = "federated-authentication"
saml_provider_arn = var.identity_provider_arn
self_service_saml_provider_arn = var.self_service_identity_provider_arn
}
When you have created your AWS Client VPN with the two Identity Providers, you can continue with the last step of this setup.
In Okta, similarly to the process of creating the ‘AWS Client VPN’ application, go to ‘Applications’ > ‘Browse App Catalog’. Search for ‘Bookmark App’ and click the ‘Add integration’ button.
In the General Settings, give it a name that the users will see in their dashboard, like ‘AWS Client VPN Portal’.
In the URL field, paste your exact AWS Self-service portal URL: https://self-service.clientvpn.amazonaws.com/endpoints/cvpn-endpoint-xxxxxx (Take it from the Client VPN configuration in the AWS console.)
Don’t tick the box that says ‘Do not display application icon to users’.
Just like with the previous two applications, assign this ‘Bookmark App’ to your already created groups – ‘dev’, ‘stage’ and ‘prod’.
Now, your users will see in their dashboard a tile with the name that you gave to the Bookmark App.
When they click on it, they will be redirected to the page where they can download the OpenVPN client configuration as well as the AWS Client VPN software for their specific operating system.
Conclusion
When choosing an Identity Provider, keep in mind the following:
- Okta allows you to enforce context-based policies specifically for the VPN. You can, for example, specify a rule that blocks users trying to authenticate from an unauthorized country.
- Okta provides granular log data regarding when and who logged in, from where, and on what device. For companies that want to be compliant with SOC2 or ISO 27001, for example, having all authentication logs (including AWS VPN access) centralized in Okta makes auditing significantly easier than pulling separate logs from AWS CloudTrail.
- Having a single source of truth for login to all corporate applications makes it easier to deactivate all the accounts of an employee leaving the company.
Read more of our blog post here.
