How to set up AWS Verified Access with Okta
Tags: aws, devops, kubernetes, javascript
Published: 2024-03-28 10:16:04

<a href="https://cicube.io/">
    <img src="https://c.cicube.io/marketing%2Fdevto-banner.png" alt="cicube site" /> 
</a>


---
## Introduction

In today's online world, keeping your information safe is really important. There are a lot of online threats out there, so it's vital to protect your data and systems. AWS Verified Access is a tool that helps with this. It gives you a secure way to control who can get into your AWS resources. This is good news for businesses big and small because it means they can be more confident about their security.

In this article, we'll discuss the fundamentals of AWS verified access and explore its configuration through examples.


## What is AWS Verified Access?

With [AWS Verified Access](https://aws.amazon.com/verified-access/), you can let people safely use your apps without needing a VPN (a secure connection). It checks every request to use an app and makes sure that people can only get in if they meet certain security rules.

AWS Verified Access boosts security by checking every app access request in real time, making it tough for unauthorized access. It links with AWS and other security services to check if users and devices are safe before letting them in.

This method also cuts down on the need for VPNs, leading to fewer technical problems and easier access for users.

## How Verified Access works?

AWS Verified Access checks each time a user wants to use an app, deciding if they can get in based on two things: information from a trusted security service you pick (either from AWS or another company) and rules you make.

When someone tries to use an app, Verified Access looks at their info from the security service and sees if it matches your rules. Users can only use the app if they meet your security needs. By default, nobody gets in until you set up these rules.

Also, Verified Access keeps track of every time someone tries to access an app, making it easier for you to handle any security problems or check who's been trying to get in.

![How verified access works?](https://c.cicube.io/blog%2F2024-03-26-aws-verified-access%2Faws-verified-diagram.png 'How Verified Access Works?')

### Verified Access Partners

[Verified Access Partners](https://aws.amazon.com/verified-access/partners/) refers to a group of selected providers that AWS Verified Access has teamed up with. These partnerships make setting things up simpler because they work seamlessly with AWS Verified Access. This means businesses can get everything up and running quickly and without hassle.

#### Trust/networks providers

Trust/Network Providers are entities that facilitate secure transactions and communications over the internet. They act as middlemen, checking identities, ensuring data is secure, and building trust in online interactions. These providers are essential for safe and dependable digital transactions, boosting confidence for users and businesses.

-   [Okta](https://www.okta.com/)
-   [CrowdStrike](https://www.crowdstrike.com/)
-   [CyberArk](https://www.cyberark.com/)
-   [duo](https://duo.com/)
-   [jamf](https://www.jamf.com/)
-   [jumpcloud](https://jumpcloud.com/)
-   [prosimo](https://prosimo.io/)
-   [pingidentity](https://www.pingidentity.com/)

#### SIEM/observability providers

SIEM (Security Information and Event Management)/observability providers are platforms or services that offer comprehensive monitoring and analysis capabilities for cybersecurity and system performance. They collect, correlate, and analyze data from various sources to detect and respond to security threats or operational issues in real-time.

These providers enable organizations to enhance their security posture, improve compliance, and optimize system performance through actionable insights derived from data analysis.

-   [Datadog](https://www.datadoghq.com/)
-   [IBM](https://www.ibm.com/)
-   [Netskope](https://www.netskope.com/)
-   [New Relic](https://newrelic.com/)
-   [Rapid7](https://www.rapid7.com/)
-   [Sumo Logic](https://www.sumologic.com/)
-   [Trellix](https://www.trellix.io/)

### AWS Verified Access DSM specifications

When setting up the AWS Verified Access DSM, having a good grasp of its specifications can ensure a smooth integration. For instance, being aware of the supported protocols beforehand can minimize any challenges during the configuration process.

Below is a table outlining the specifications for the AWS Verified Access DSM:

| Specification               | Value                                                                                                                                          |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| Manufacturer                | Amazon                                                                                                                                         |
| DSM                         | AWS Verified Access                                                                                                                            |
| RPM name                    | DSM-AWSVerifiedAccess-QRadar_version-Build_number.noarch.rpm                                                                                   |
| Supported protocols         | [Amazon AWS S3 REST API](https://www.ibm.com/docs/en/SS42VS_DSM/com.ibm.dsm.doc/t_dsm_guide_Amazon_AWS_ct_Amazon_AWS_REST_API.html) & `Syslog` |
| Event format                | JSON                                                                                                                                           |
| Automatically discovered?   | Yes                                                                                                                                            |
| Includes identity?          | Yes                                                                                                                                            |
| Includes custom properties? | Yes                                                                                                                                            |
| More information            | [AWS website](https://aws.amazon.com/)                                                                                                         |

## How to use AWS Verified Access with Okta?

We'll demonstrate Okta configuration in six steps.

### Prerequisites

-   An AWS account
-   An [Okta](https://okta.com) account
-   An instance running webserver
-   Public Domain with TSL/SSL certificate

### Step 1: Configure OIDC application in Okta

I begin by creating a user and a group that we'll use to try out getting into AVA.

-   After you sign in to [Okta](https://developer.okta.com/login/), click on `Directory`, then `Groups`, and choose `Add Group` from the menu on the left. Type in a name for the group and save it. Remember the name of this group because you'll use it later when setting up the rules for getting in. Let's call this group `Marketing Team` for our example.

![Okta Groups Marketing Team](https://c.cicube.io/blog%2F2024-03-26-aws-verified-access%2Fokta-groups.png 'AWS verified access Okta Groups')

-   Assign yourself/users to this group

### Step 2: Create an OIDC application in Okta

To link AVA with Okta, you need to add it as an OIDC app. Here's how:

![Okta Create App Integration](https://c.cicube.io/blog%2F2024-03-26-aws-verified-access%2Fokta-create-web-app.png 'Aws verified Okta Create App Integration')

1. Click on `Applications` in the menu on the left side.
2. Choose `Create App Integration`.
3. For the sign-in method, pick `OIDC - OpenID Connect`.
4. For the application type, choose `Web Application`.
5. Name your app integration `CI Cube App`.
6. For sign-in redirect URIs, put in `https://cicube.aws.dev/oauth2/idpresponse`.
7. Under assignments, choose `Controlled access` to let everyone in your company use it. If you want, you can limit it to certain groups by picking `Limit access to selected groups` and typing in the group name.

![Okta Created App Integration](https://c.cicube.io/blog%2F2024-03-26-aws-verified-access%2Fokta-created-web-app.png 'Okta Created App Integration')

After you make the application:

1. Copy the Client ID and Client Secret because you'll need them later for Verified Access.
2. Click on `Application`, find `CI Cube App`, and go to `Sign On`. Look for the `Groups claim filter`, pick `matches regex`, and type in `.*`. This tells it to send back all the user groups when someone signs in. Check the Okta help guide for more on group claims.

![Okta Group Claim Policy](https://c.cicube.io/blog%2F2024-03-26-aws-verified-access%2Fokta-group-claim-filter.png 'AWS verified access Okta Group Claim Policy')

### Step 3: Set up Verified Access in AWS

Setting up Verified Access involves four main steps:

-   Set up a Trust Provider.
-   Make an Access Instance.
-   Form an Access Group.
-   Establish an Access Endpoint.

1. Go to the [VPC page](https://console.aws.amazon.com/vpcconsole/home) and choose `Verified Access trust provider` from the menu on the left.
2. For the policy reference name, type in a name you'll use later for policy rules. Let's use `Okta_CI_CUBE_Test` for our example.
3. Choose `User trust provider` for the trust provider type.
4. Pick `OIDC (OpenID Connect)` as the user trust provider type.

![Verified Access Trust Provider](https://c.cicube.io/blog%2F2024-03-26-aws-verified-access%2Faws-verified-create-access-trust-provider.png 'Verified Access Trust Provider')

For the next parts, you'll need info from Okta's OpenID Connect & OAuth 2.0 API. Go there and look for `/.well-known/openid-configuration`. Make a GET call as instructed, and be sure to replace `${YOUR_OKTA_DOMAIN}` with your actual Okta sign-in URL.

```sh
GET https://${YOUR_OKTA_DOMAIN}/.well-known/openid-configuration
```

For instance, type this into your web browser's address bar:

[https://dev-00000000-admin.okta.com/.well-known/openid-configuration](https://dev-00000000-admin.okta.com/.well-known/openid-configuration)

This will show you details like the issuer, authorization endpoint, token endpoint, and userinfo endpoint.

1. Issuer: Type in your Okta login URL, for example, `https://dev-00000000.okta.com`.
2. Authorization endpoint: Use your login URL followed by /oauth2/v1/authorize, like `https://dev-00000000.okta.com/oauth2/v1/authorize`.
3. Token endpoint: Add /oauth2/v1/token to your login URL, making it `https://dev-00000000.okta.com/oauth2/v1/token`.
4. User endpoint: This is your login URL plus /oauth2/v1/userinfo, such as `https://dev-00000000.okta.com/oauth2/v1/userinfo`.
5. Client ID and Client Secret: Find these in your Okta app under `Applications`, then `CI Cube App`, and look in `General`.
6. Scope: Type `openid profile groups`. Including these scopes lets AVA access various user details for making decisions on who gets in.

![Verified Access Trust Provider Step 2](https://c.cicube.io/blog%2F2024-03-26-aws-verified-access%2Faws-verified-create-access-trust-provider-2.png 'Verified Access Trust Provider Step 2')

### Step 4: Set up an Access Instance

To make a Verified Access Instance, follow these steps:

1. Fill in any optional details like a Name tag and description.
2. Under Verified Access trust provider, choose the trust provider you set up before.

![Verified Access Instance](https://c.cicube.io/blog%2F2024-03-26-aws-verified-access%2Faws-verified-access-control-access-instance.png 'AWS Verified Access Instance')

### Step 5: Set up an Access Group

To set up a Verified Access Group, do this:

1. Enter optional details like a Name tag and description.
2. Choose the Verified Access Instance you made before, under Verified Access Instance.
3. We'll make the policy later on.

![Verified Access Group](https://c.cicube.io/blog%2F2024-03-26-aws-verified-access%2Faws-verified-access-control-access-access-group.png 'Verified Access Group')

Before you set up an endpoint, you need to get a [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) certificate from [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) first. Make sure the certificate's domain name matches the public domain name that your users will type in to get to your application.

To set up an endpoint, which will have its own DNS name and TLS certificate, follow these steps:

1. Choose the Verified Access Group you created before.
2. For the Application domain, type in a DNS name for your app. Here, we'll use it.jagdalet.people.aws.dev as an example.
3. Select the public TLS certificate you requested earlier for the Domain certificate ARN.
4. For Attachment type, pick VPC.
5. Choose the security groups for the endpoint under Security-group. These groups will apply to traffic going from the Verified Access Endpoint into your load balancer.
6. Type in a custom identifier for the Endpoint domain prefix. This will be added to the start of the DNS name created by Verified Access for the endpoint.
7. Set the Endpoint type to Load balancer and select the correct Protocol, Port, Load balancer ARN, and subnets.

![Verified Access Endpoint](https://c.cicube.io/blog%2F2024-03-26-aws-verified-access%2Faws-verified-access-access-endpoint.png 'Verified Access Endpoint')

**Tip**:
Creating Wildcard Certificates
An important thing to note about Verified Access is that it doesn't allow the use of wildcard certificates. While this might increase security in theory, it means you have to create a certificate for a specific domain or subdomain

```sh
certbot certonly --manual -d xxx.cicube.io
```



### Step 6: Set up a policy

To set up Access policies, you'll use [Cedar](https://www.cedarpolicy.com/), which is AWS's policy language. Remember, the name you see after `context` should match the Policy reference name you chose when creating the Verified Access trust provider. For more details on how to write these policies, including syntax, attributes, and how to use operators, check the documentation page.

Here's an example of a policy that means access to the application is only given if the user belongs to the `Marketing Team` group.

![Verified Access Policy](https://c.cicube.io/blog%2F2024-03-26-aws-verified-access%2Faws-verified-access-policy-example.png 'Verified Access Policy')

Scopes let a user decide what information an OIDC client can see about them. This could include things like their profile, email, or phone number, which are kept by an identity provider that follows OIDC standards. To know which scopes you can use, you should look at the [Okta documentation](https://developer.okta.com/docs/api/oauth2/).

Here's an example policy that makes sure the user is in the `Maerketing Team` group, has an email address ending with @cicube.io.

```
permit(principal,action,resource)
when {
  //user must be in Marketing Team group on Okta side with cicube.io in email
  context.Okta_Test.groups.contains("Marketing Team") &&
  context.Okta_Test.email like "*cicube.io"
};
```

After you create the Endpoint, in the details section, you will find the public DNS name of the endpoint.

Take the public DNS name of the endpoint and make a CNAME record for your application's domain in an [Amazon Route 53](https://aws.amazon.com/route53/) Public Hosted Zone.

To check if everything is working, open a browser in Incognito mode and go to your application. For this test, log in with a user who is in the Engineering group on Okta. In this example, there's a simple Apache web server set up behind an ALB. When I visited `https://test.cicube.io/`, it sent me to the Okta login page. After I put in my login details, I was able to get into my application.



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6b3udoqy3z3g16ntq8ae.png)




### Conclusion

In this post, we covered how to integrate [AWS Verified Access](https://aws.amazon.com/verified-access/) with [Okta](https://www.okta.com/) as an external Identity Provider (IdP). This setup allows users to securely access corporate applications from anywhere over the internet without needing a VPN. This approach simplifies the experience for both IT administrators and users, all while prioritizing security.