Introducing AWS Verified Access – General Availability

Introduction

AWS Verified Access enables customers to provide VPN-less, secure access to their corporate applications. We released it as a preview during AWS re:Invent 2022. Today, we are happy to announce that this service is now generally available (GA).

Built using AWS Zero Trust principles, customers can use Verified Access to reduce the risks associated with remote connectivity. IT administrators and developers can define fine-grain access per application using real-time contextual signals, including identity and device posture. Verified Access also simplifies security operations. Customers can manage policies for each application all in one place.

To easily verify users against specific security requirements, Verified Access integrates with identity and device security partners that our customers’ trust, including: Beyond Identity, CrowdStrike, CyberArk, Cisco Duo, Jamf, JumpCloud, Okta, and Ping Identity. In addition, observability partners – including Datadog, IBM, New Relic, Rapid7, Sumo Logic, and Trellix — can ingest Verified Access logs and provide actionable data from the users trying to access customer applications.

New Features

Since the launch of the public-preview, at re:Invent 2022, we have added two new features.

First, Verified Access now supports integration with AWS Web Application Firewall (WAF) to protect web applications (HTTP/S) from application-layer threats. You can now filter out common exploits, such as SQL injection and cross-site scripting (XSS) using AWS WAF, while enabling AWS Zero Trust based fine-grained access for your applications using user identity and device security status. AWS WAF lets you monitor the HTTP(S) requests that are forwarded to your protected application endpoints. You do this by defining a web access control list (Web ACL) and then associating it with one or more Verified Access instances you want to protect.

AWS WAF is enabled on a per Verified Access instance basis and adheres to the rules you defined for your application endpoints. When a user requests access to an application behind Verified Access, AWS WAF will inspect the HTTP request. Using AWS WAF rule statements, you can provide matching criteria and the action to take on matches, including permitting or blocking the traffic. AWS WAF permits or blocks the traffic before handing the traffic over to Verified Access for an endpoint policy evaluation. Find more information on this in the Verified Access documentation.

Second, Verified Access now supports passing signed identity context to your application endpoints. Previously, users would request access to the application behind Verified Access with both identity and device claims, but the claims were not available to the end applications. Verified Access now passes signed identity context, including things like email, username, and other attributes from the identity provider to the applications. This enables you to personalize your application using this context, eliminating the need to re-authenticate the user for personalization. The signed context allows the application to verify cryptographically that Verified Access has authenticated the request.

After Verified Access authenticates the user successfully and permits the request, it sends the user claims received from your identity trust provider to the application endpoint. Verified Access signs the user’s claim so that your applications can verify the user’s identity and sends an HTTP header (x-amzn-ava-user-context) to the application endpoints in the format of a signed JSON Web Token (JWT). These claims are received by either your OIDC provider or the AWS Identity Access and Management (IAM) Identity Center. The JWT header is a JSON object with the following fields:

{
"alg": "ES384",
"kid": "12345678-1234-1234-1234-123456789012",
"signer": arn:aws:ec2:us-west-2: 555555555555:verified-access-instance/vai-555555555555", 
"iss": "https://subdomain.example.com"
"exp": "1678813602"
}

The JWT payload is a JSON object that contains the user claims received from the identity trust provider. For example, the following payload is from IAM IDC:

{
    "user": {
        "user_id": "f478d4c8-a001-7064-6ea6-5a57d344a4fb",
        "user_name": "test-123",
        "email": {
            "address": "test@example.com",
            "verified": false
        }
    }
}

Find more information on how this works and validating the signature in the documentation.

Customer Architectures

During the preview launch, we worked with customers on migrating several common use cases. The following are the two most common architecture patterns we see from customers and considerations when moving the applications to Verified Access.

The first common architecture we saw was corporate applications protected by AWS Site-to-Site VPN, as shown in the following figure. In this architecture, users can only access the application if they are at a branch site connected to AWS by Site-to-Site VPN. For many of these applications, there is an implicit trust model where, if users are on the VPN, then they have access to the application. Authentication and login for users occurs at the application itself, requiring additional development. However, there are no additional checks outside identity that are included in the request. For these customers, the Application Load Balancer (ALB) is an internal Load Balancer, while routing is enabled through Site-to-Site VPN or Client VPN.

Figure 1 – Corporate applications with Site-to-Site VPN

The second common architecture we see is an Internet facing corporate application, as shown in the following figure. In this architecture, users can access the application over the Internet. Many customers have integrated their Internet facing ALB with both AWS WAF and an OIDC provider. Users are authenticated at the ALB and user claims are sent from the ALB to the instances using HTTP header x-amzn-oidc-data. Documentation of this process can be found in the Application Load Balancing documentation. The application consumes this header to identify the authenticated users, but device health and other contexts aren’t verified by the ALB.

Figure’2 – Internet facing corporate applications

As customers look to migrate the applications to Verified Access, the following are things to consider:

• Internal ALB: Verified Access requires the ALB to be an internal facing ALB. For the first common architecture, this is already the case, but customers would need to change the ALB in the second architecture to support the ALB behind Verified Access.
• WAF Integration: With support of WAF at the instance level within Verified Access, existing application that have WAF integration with ALB can move the policies from the ALB to the Verified Access instance.
• Cedar Policy: Verified Access provides for centralized policy enforcement to grant access to the application behind Verified Access. Customers can use Cedar policies to permit and forbid access to the applications. The policies can be written at the group level or the endpoint level, depending on the customer’s need.
• User Claims: With Verified Access passing the user claims through HTTP headers to the application, the application needs to use the x-amzn-ava-user-context HTTP header to identity the user accessing the application.

Figure 3 – Corporate application behind Verified Access

Conclusion

In this post, we announced the GA of AWS Verified Access. We discussed the two new features, AWS WAF integration and passing signed identity context to end applications, launched as part of GA. We also discussed common architectures we’re seeing from customers and architecture considerations when moving those applications behind Verified Access.

Verified Access is now available and you can find more information in the What’s New post and on the Verified Access documentation page. On-board your applications to Verified Access today to simplify connectivity with enhanced security capabilities for your enterprise applications.