AWS Verified Access Integration with 3rd party identity providers

AWS Verified Access (AVA) offers a solution to the challenges faced by enterprises by managing remote workforce connectivity through traditional remote access VPNs. It allows remote employees to securely access corporate applications over the Internet while authenticating and authorizing each request.

Unlike traditional VPN systems, which lack granularity for application-level authentication and authorization, AVA implements the AWS Zero Trust security principles and OIDC protocols, providing better security for modern enterprise applications.

AVA evaluates each application request and authorizes it based on various conditions, making sure that only validated requests are granted access. With support for multiple OIDC-supported identity providers, AVA simplifies the process of securing remote access to corporate applications.

In a recently published post, we covered the basics of AVA and how to integrate it with AWS Identity Center. In this post, I cover steps to integrate AVA with Okta identity provider. Refer to the respective vendor documentation for integrations with other IdPs.

Solution overview

In this architecture, I integrate AVA with Okta OIDC and protect an application hosted behind an internal ALB. Note that the walkthrough is an example and the integration details for the production implementation may vary.

Figure 1: AVA integration with Okta

Below are the main components in AVA architecture:

• Verified Access Instances – An instance evaluates application requests and grants access only when your security requirements are met.
• Verified Access Endpoints – Each endpoint represents an application. You can create a load balancer endpoint (Network Load Balancer (NLB) or Application Load Balancer (ALB)) or a network interface endpoint.
• Verified Access Group – A collection of Verified Access Endpoints. We recommend that you group the endpoints for applications with similar security requirements to simplify policy administration. For example, you can group the endpoints for all of your sales applications together.
• Access policies – A set of user-defined rules that determine whether to allow or deny access to an application. You can specify a combination of factors, including user identity and device security state (device security state is applicable if you configure an integration with device management solutions such as CrowdStrike or Jamf). You create a group access policy for each Verified Access Group, which is inherited by all of the endpoints in the group. You can optionally create application-specific policies and attach them to specific endpoints.
• Trust providers – A service that manages user identities or device security state. Verified Access works with both AWS and third-party trust providers. You must attach at least one trust provider to each Verified Access Instance. You can attach a single identity trust provider and multiple device trust providers to each Verified Access Instance.
• Trust data – The security data for users or devices that your trust provider sends to Verified Access. For example, the email address of a user or the group to which the user belongs. Verified Access evaluates this data against your access policies when it receives each request to access an application.

Prerequisites

 The following prerequisites are required to follow along with this post: 

• AWS Account
• An instance running webserver
  • Setting up Amazon VPC
  • Install a web server on your EC2 instance
• An Internal ALB
• To complete the walkthrough, you must have a Public domain available where you will be creating a hostname to access the application.
• A public TLS/SSL certificate imported into or created with ACM

Note that the certificate name must match with the hostname that will be used for AVA.

Walkthrough

Configure OIDC application in Okta

I start by setting up a user and group that will be used for access testing via AVA.

User and group 

1. Log in to your Okta developer account here.
2. Once signed in: on the left navigation pane select Directory → Groups → Add Group
   Provide a Name and save. Note that this group Name will be used in verified-access policy condition clause. For this example, it’s Engineering
3. Select the group followed by Assign people
4. Assign yourself/users to this group

Figure 2: Okta Groups configuration

Building application in Okta

 To integrate AVA with Okta, you must set it up as an OIDC application by following the steps below: 

1. On the left navigation pane select Applications
2. Select Create App Integration
3. Sign-in method: Select OIDC – OpenID Connect
4. Application type: Select Web Application
5. App integration name: My Web App
6. Sign-in redirect URIs: https://it.jagdalet.people.aws.dev/oauth2/idpresponse
7. Assignments: Controlled access – Allow everyone in your organization to access (you can optionally select ‘Limit access to selected groups’ and provide the group name)

Once the application is created:

1. Copy the ClientID and Client Secret, as this will be required later to be used in Verified Access
2. Go to Application → My Web App → Sign On. Under Groups claim filter, select ‘matches regex’ and enter “.*” See Okta documentation for more information on Using Groups Claim

This setting controls which groups are returned back to the application when the user authenticates. The customer should include all groups or at least the ones on which they want to make an authorization decision. Enter .* to return all of the user’s Groups.

.*groupA.*|.*groupB.*|.*groupC.*|.*groupD.* This will send the groups A, B, C, and D.

In this example, the user is part of only one group.

Figure 3: Okta Groups Claims configuration

AVA

Creating a Verified Access setup is a four-step process as listed below:

• Create Trust provider
• Create Access Instance
• Create Access Group
• Create Access Endpoint

To get started, navigate to the VPC page of the AWS Management Console.

Create Trust provider

Select Verified Access trust provider on the left-side navigation pane.

1. Policy reference name: Enter an identifier to use later when working with policy rules. For this example, it’s Okta_Test.
2. Trust provider type: Select User trust provider
3. User trust provider type: Select OIDC (OpenID Connect)

For the next four fields, the information can be obtained by going to Okta OpenID Connect & OAuth 2.0 API, then select /.well-known/openid-configuration. Run the following GET call. Replace ${yourOktaDomain} with your Okta sign-in URL

GET https://${yourOktaDomain}/.well-known/openid-configuration

For example, paste the following in the browser:

https://dev-12345678-admin.okta.com/.well-known/openid-configuration

This should return the issuer, authorization_endpoint, token_endpoint, and userinfo_endpoint information.

1. Issuer: Enter Okta log in URL, example: https://dev-12345678.okta.com
2. Authorization endpoint: https://<login URL>/oauth2/v1/authorize
   Example: https://dev-12345678.okta.com/oauth2/v1/authorize
3. Token endpoint: https://<login URL>/oauth2/v1/token
   Example: https://dev-12345678.okta.com/oauth2/v1/token
4. User endpoint: https://<login URL>/oauth2/v1/userinfo
   Example: https://dev-12345678.okta.com/oauth2/v1/userinfo
5. Client ID and Client secret: Get the Client ID and Client secret from Okta application
   Applications → My Web App → General
6. Scope: openid profile groups (Adding scopes allows AVA to get access to different user attributes to make an authorization decision)

Note that Okta supports these scopes for OIDC currently. Change the scope configuration appropriately if you want to include multiple scopes.

Figure 4: AWS Verified Access Trust Provider configuration

Create Verified Access Instance

Use the following procedure to create a Verified Access Instance.

1. Provide the optional details (Name tag and description)
2. Verified Access trust provider → Select the trust provider that was created earlier

Figure 5: AWS Verified Access Instance configuration

Create Verified Access Group

Use the following procedure to create a Verified Access Group.

1. Provide the optional details (Name tag and description)
2. Verified Access Instance → Select the Verified Access Instance created earlier
3. We will create the policy later

Figure 6: AWS Verified Access Group configuration

Before creating an endpoint, as a prerequisite you must request the TLS certificate in ACM. The certificate domain name must match the public domain name that your users will use to access your application.

Figure 7: AWS ACM request TLS Certificate

Create endpoint

Each endpoint has its own DNS name and TLS certificate.

1. Verified Access Group: Select the Verified Access Group that was created earlier.
2. Application domain: Enter a DNS name for your application. In this example I will be using it.jagdalet.people.aws.dev.
3. Domain certificate ARN: Choose the public TLS certificate that we created earlier.
4. Attachment type: VPC.
5. Security-group: Choose the security groups for the endpoint. Traffic from the Verified Access Endpoint that enters your load balancer will be associated with this security group.
6. Endpoint domain prefix: Enter a custom identifier to prepend to the DNS name that Verified Access generates for the endpoint.
7. Endpoint type: Load balancer. Select the appropriate Protocol, Port, Load balancer ARN, and subnets.

Note that HTTPS load balancers can use either self-signed or public TLS certificates.

Figure 8: AWS Verified Access Endpoint Configuration

Configure Access policies 

Policies are written in Cedar, an AWS policy language. Note that the name after context is the name entered as the Policy reference name when we created the Verified Access trust provider. The documentation page has details of the policy syntax, attributes, and operators that you can use.

Here I am showing an example policy which says access to the application will be granted only if the user is part of the Engineering group.

Figure 9: AWS Verified Access policy Configuration

Scopes are a set of permissions that a user grants to an OIDC client. They define the access that a client has to the user’s information, such as the user’s profile, email address, or other details stored in an OIDC-compliant identity provider. To see the supported scopes, see the Okta documentation.

As an example, if you must access the email or phone number for the user, then you must add those scopes to your AVA trust provider.

When creating the context of an AVA policy using various conditions, as discussed in Policy statement structure, you can use the && operator to add additional conditions.

Here I am showing an example policy that will check to make sure that the user is in Engineering group, has an amazon.com email address, and uses a specific phone number

The example policy would look like the following:

  permit(principal,action,resource)
  when {
      //user must be in Engineering group on Okta side with amazon.com in email and specific phone number 
    context.Okta_Test.groups.contains("Engineering") &&
    context.Okta_Test.email like "*amazon.com" &&
    context.Okta_Test.phone_number == "2171234567"
  };

Once the Endpoint is created, under details you should see the endpoint public DNS name.

Figure 10: AVA Endpoint DNS

Use this public DNS name and create a CNAME record for your application domain in an Amazon Route53 Public Hosted Zone.

Figure 11: Entry in an Amazon Route53 Public Hosted Zone

Test connectivity to the application using a browser in Incognito mode. When you log in with the user who is part of the Engineering group in Okta, you should be able to access the application. In this example I am running a simple Apache web server behind an ALB. Initial page of https://it.jagdalet.people.aws.dev/ redirected me to the Okta login, after entering the credentials I was able to login to my application.

If a user from another Okta group tries to log in, then there would be a 403 Unauthorized error.

Conclusion

In this post, we saw the integration of AVA with Okta as an external IdP. Using this architecture, users can connect to the corporate Applications from anywhere over the internet in a tunnel-less fashion, thereby making both the IT administrator and user’s life easy while keeping security as a priority.

Get started today with AVA by checking the documentation and visiting the AWS console.

Watch re:Invent 2022 – Introducing AWS Verified Access: Secure connections to your apps (NET214)