Integrating AWS Verified Access with Jamf as a device trust provider

In this post, we discuss how to architect Zero Trust based remote connectivity to your applications hosted within Amazon Web Services (AWS). Specifically, we show you how to integrate AWS Verified Access with Jamf as a device trust provider. This post is an extension of our previous post explaining how to integrate AWS Verified Access with CrowdStrike. In this post, we also look at how to troubleshoot Verified Access policies and integration issues for when a user with valid access receives access denied or unauthorized error messages.

Verified Access is a networking service that is built on Zero Trust principles and provides secured access to corporate applications without needing a virtual private network (VPN). This enables your corporate users to be able to access their applications from anywhere with a complaint device. Verified Access reduces IT operations overhead because it is built on an open environment and integrates with your existing trust providers and lets you use your existing implementations.

Verified Access lets you centrally define access policies for your applications with additional context beyond only IP address, using claims from user identity and user device coming from the trust providers. Using these access policies, Verified Access evaluates each access request at scale in real time and records each access request centrally, making it easier and quicker for you to respond to security incidents or audit requests.

Jamf is an Apple mobile device management (MDM) software and security provider. Organizations can use Jamf to manage their corporate devices and maintain security posture. Jamf’s Zero Trust product—Jamf Trust—monitors device security posture and reports it back to the administrators on the Jamf Protect console. It monitors the device’s OS settings, patch level, and device settings against an organization’s defined policy and calculates device posture from secure to high risk.

Verified Access integrates with third-party device management providers such as Jamf to gather additional security claims from the device in addition to user identity to either allow or deny access.

Solution overview

In this example, you will set up remote access to a sales application and an HR application. Through the solution, you want to make sure only users from the sales group can access the sales application, and only users from the HR group are able to access the HR application.

You will onboard the applications to Verified Access, and access policies will be defined based on the security requirements using Cedar as the policy language. After you have onboarded the applications and have defined the access policies, engineers and users will be able to access the application from anywhere using the Verified Access endpoint without needing a VPN.

You will also use the claims coming from the device in the access policies to make sure that device is managed by Jamf and is secure—for example, that the device is at the right patch level or there are no security vulnerabilities—before granting user access to the respective application.

Figure 1: High-level solution architecture

Prerequisites

To integrate Verified Access with Jamf device trust provider, you need to have the following prerequisites.

Verified Access:

Enable AWS IAM Identity Center for your entire AWS Organization. If you don’t have it enabled, follow the steps to enable AWS IAM Identity Center
Have users created and mapped to respective groups under AWS IAM Identity Center
Apple device (EC2 Mac for this demo)
Subscription with Jamf Pro and Jamf Security (RADAR)
Jamf tenant ID

Jamf:

Managed devices with Jamf Pro
Volume purchasing for app deployment
MacOS 12 or later

Walkthrough

For this demo, you will use Amazon Elastic Compute Cloud (Amazon EC2) Mac instances, which will be enrolled and managed by Jamf. Because EC2 Mac instances don’t come with MDM capabilities out of the box, you can use the following steps to enroll an EC2 Mac instance with Jamf.

Enroll EC2 Mac instance with Jamf

To start, you need to create some credentials and store them in AWS Secrets Manager. These credentials are Jamf endpoint, Jamf user and password with enrollment privileges, and the EC2 Mac instance local admin and the password. We have used AWS Secrets Manager for this demo, but if desired, you could use Parameter Store, a capability of AWS Systems Manager. You can find AWS CloudFormation and Terraform templates for both Secrets Manager and Systems Manager at our sample code on GitHub.

The CloudFormation template will create:

jamfServerDomain – This is your organization’s Jamf URL, the endpoint for your device to get the enrollment from.
jamfEnrollmentUser – This is the authorized user within Jamf with device enrollment permissions.
jamfEnrollmemtPassword – This is the password for the enrollment user provided in number 2.
localAdmin – This is the admin user on your EC2 Mac instance, with the permissions to install required profiles and apply changes.
localAdminPassword – This is the password for the admin user on your EC2 Mac instance provided in number 4.

The CloudFormation template also creates a Secrets Manager secret, an AWS Identity and Access Management (IAM) policy, a role, and an instance profile.

To allocate a Dedicated Host and launch an EC2 Mac instance

After you complete deploying the CloudFormation template, allocate an Amazon EC2 Dedicated Host for Mac and launch an EC2 Mac instance on the host. On the Launch an instance screen, after providing the basic details, expand the Advanced details section and select the IAM instance profile that was created as part of CloudFormation deployment.

Figure 2: Advanced details pane showing the selected IAM instance profile

To configure the instance:

Connect to your EC2 Mac instance using Secure Shell (SSH).

Figure 3: The steps for connecting to the instance using SSH client

Enable screen sharing and set the admin password to the one you used when creating credentials. Use the following command:

sudo /usr/bin/dscl . -passwd /Users/ec2-user 'l0c4l3x4mplep455w0rd' ; sudo launchctl enable system/com.apple.screensharing ; sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.screensharing.plist

After screen sharing is enabled, connect to the EC2 Mac instance using VNC Viewer or a similar tool and enable automatic login from System Settings – > Users & Groups
Place the AppleScript provided on the GitHub in /Users/Shared:
1. You can either download the script to your local machine and then copy it over or download the script directly to the EC2 Mac instance.
2. If you are using VNC Viewer to connect to the instance, you should be able to drag and drop the file from your local machine to the EC2 Mac instance.
Edit and update the AppleScript with the secret ID from Secrets Manager for the MMSecret variable:
1. MMSecret is the secret from the Secrets Manager that was created as part of the CloudFormation template deployment. Copy the secret Amazon Resource Name (ARN) from the Secrets Manager console or use the AWS Command Line Interface (AWS CLI) to get the ARN and update it in the AppleScript.
Run the AppleScript using the following command and allow access to Accessibility, App Management, and Disk Access permissions for the script. While the script is running, the screen might flash a few times.
```
osascript /Users/Shared/enroll-ec2-mac.scpt --setup
```
After you see the Successful message, choose OK and restart the instance. After the instance has restarted, sign in to the instance and the enrollment will proceed.

The enrollment will take a few minutes and your EC2 Mac instance will receive the profiles and policies from the Jamf instance as configured by your administrator.

Jamf end setup for Verified Access

In this section, you will be working on your Jamf security portal, RADAR, to integrate Verified Access with Jamf, and then onboard your applications to Verified Access and define access policies. You begin this walkthrough by enabling Verified Access on Jamf first.

Jamf Protect and Jamf Trust are the components that collect device claims and share them with Verified Access. The following section illustrates how to make Jamf ready to send claims over to Verified Access. This section needs to be completed on Jamf Security and Jamf Pro Portals. Jamf UI can differ depending on the Jamf Pro version used.

To enable Verified Access profile and deploy Jamf Trust and Verified Access browser extensions

Create an AWS Verified Access activation profile:
1. Go to Jamf RADAR portal -> Devices -> Activation profiles.
2. Choose Create profile. If presented with an option, choose Jamf Trust.
3. Select Device identity from the options available and choose Next.
4. Select Without identity provider and Assign random identifier and choose Next.
5. Leave the following sections as they are and continue to choose Next until you reach the review screen.
6. Choose Save and Create.
Download the manifest files:
1. Select the profile created in Step 1.
2. Select your UEM (Jamf Pro in our case).
3. Select your OS (macOS in our case).
4. Download Configuration profiles and Browser manifests.
Deploy Jamf Trust using Jamf Pro:
1. For Jamf Trust, go to the App Store apps in your Jamf Pro instance.
2. Search for and add Jamf Trust for deployment.
3. For deployment method, select Install Automatically.
4. Define scope for target computers and save.
Deploy configuration profiles using Jamf Pro:
1. Navigate to Configuration Profiles.
2. Choose Upload and select the configuration file downloaded from the RADAR portal and upload it.
3. In the General payload configuration tab, select basic settings and distribution method.
4. Define scope for target computers and choose Save.
Deploy browser extensions using Jamf Pro:
1. Navigate to Settings -> computer management, choose Packages, and choose New.
2. Use the general pane to define basic settings.
3. Select Choose File and select the Verified Access PKG file downloaded from the RADAR portal to upload and choose Save.
4. Navigate to Policies under Computers and choose New to create a new policy and use the general pane to define basic settings.
5. Select Packages and choose Configure.
6. Choose Add for the package you want to install and choose Install under Actions.
7. Define scope for target computers and choose Save.
Create and deploy Verified Access browser extensions (Google Chrome):
1. In Jamf Pro, at the top of the sidebar, select Computers. In the sidebar, select Configuration Profiles and choose New.
2. In General, use the default basic settings, including the level at which to apply the profile and the distribution method.
3. Select the Application & Custom Settings, and then choose External Applications and choose Add.
4. In the Source section, from the Choose source pop-up menu, choose Jamf Repository.
5. In the Application Domain section, choose com.google.chrome. Select the default options for version and variant choices.
6. Choose Add/Remove properties and deselect the Cloud Management Enrollment Token and, in the Custom Property field, enter ExtensionInstallForcelist, then choose Add and choose Apply.
7. In the ExtensionInstallForcelist pop-up menu, select Array. For item 1, select String from the pop-up menu, and enter the following ID for the Google Chrome browser extension: aepkkaojepmbeifpjmonopnjcimcjcbd.
8. Select the Scope tab and configure the scope of the profile and choose Save.
Create and deploy Verified Access browser extensions (Firefox):
1. In Jamf Pro, at the top of the sidebar, select Computers.
2. Select Configuration Profiles in the sidebar and choose New.
3. In General, use the default basic settings, including the level at which to apply the profile and the distribution method.
4. Select the Application & Custom Settings payload, choose External Applications > Upload, and choose Add.
5. In the Preference Domain field, enter org.mozilla.firefox.
6. Use the following code to create the desired policies for browser extension behavior. Key-value pairs in the following sample PLIST can be modified to match desired policy options.
```
<dict>
<key>EnterprisePoliciesEnabled</key>
<true/>
<key>ExtensionSettings</key>
<dict>
<key>verified-access@amazonaws</key>
<dict>
<key>install_url</key>
<string>https://addons.mozilla.org/firefox/downloads/latest/aws-verified-access/latest.xpi</string>
<key>installation_mode</key>
<string>normal_installed</string>
</dict>
</dict>
</dict>
```
7. Select the Scope tab and configure the scope of the profile and choose Save.

To obtain your Jamf tenant ID for integrating with Verified Access:

Navigate to your Jamf Security console.
Navigate to Integrations and choose Access providers.
Choose Verified Access and choose the connection name.
Your Jamf Customer ID is your tenant ID you’ll use during the setup of integration.

Figure 4: Jamf tenant ID

To review your managed device posture within the Jamf security console:

Navigate to your Jamf Security console.
Navigate to Reports -> Security -> Device view to review current device posture of your managed devices.

Figure 5: Device posture within Jamf

Verified Access setup

There are four steps to onboard your applications to Verified Access:

Onboard Verified Access trust providers.
Create a Verified Access instance.
Create one or more Verified Access groups.
Onboard your application and create Verified Access endpoints.

The following steps explain in detail how to onboard your applications to Verified Access.

Step 1: Onboard Verified Access trust providers

Create a user trust provider

Open the Amazon VPC console. In the navigation pane, choose Verified Access trust providers, and then Create Verified Access trust provider.
Provide a Name and Description. The screenshot shows identitycenter-trust-provider as the name and Identity Center as trust provider as the description.
Provide a Policy Reference name that you will use later while defining policies. This screenshot shows idcpolicy as the policy reference name.
Select User Trust Provider.
Select IAM Identity Center.
Provide additional tags.
Choose Create Verified Access trust provider.

Figure 6: This screenshot shows that user identity trust providers have been created

Create a device trust provider

Open the Amazon VPC console. In the navigation pane, choose Verified Access trust providers, and then Create Verified Access trust provider.
Provide a Name and Description. The screenshot shows device-trust-provider as the name and Jamf as device trust provider as the description.
Provide a Policy Reference name that you will use later while defining policies. The screenshot shows jamfpolicy as the policy reference name.
Select Device trust provider.
In Device details, provide the Jamf tenant ID that you obtained from the Jamf Security console.
Provide additional tags.
Choose Create Verified Access trust provider.

Figure 7: This screenshot shows the device trust provider has been created

Step 2: Create a Verified Access instance

Open the Amazon VPC console. In the navigation pane, choose Verified Access instances, and then Create Verified Access instance. Provide a Name and Description.
From the dropdown list, select one of the trust providers you created in Step 1. You can only select one trust provider at the time of instance creation.
Provide additional tags and choose Create Verified Access instance.
After the instance is created, select the instance and choose Actions.
Choose Attach Verified Access trust provider.
Select the other trust provider from the dropdown list and choose Attach Verified Access trust provider.

Figure 8: The Verified Access instance has been created with both trust providers attached

Step 3: Create Verified Access groups

Open the Amazon VPC console. In the navigation pane, choose Verified Access groups, and then Create Verified Access group.
Provide a Name and Description. The screenshot shows hr-group for the name and AVA Group for HR application as the description.
Select the Verified Access instance from the dropdown list that you created in Step 2.
Leave policy empty for now. You will define the access policy later.
Choose Create Verified Access group.

You need to repeat the preceding steps for HR applications, creating two groups, one for each application.

Figure 9: HR group successfully created

Step 4: Create Verified Access endpoints

Before proceeding with the endpoint creation, make sure you have your application deployed with an internal Application Load Balancer, and you have requested an ACM certificate for your public domain that your users will use to access the application.

Open the Amazon VPC console. In the navigation pane, choose Verified Access endpoints and then Create Verified Access endpoint.
Provide a Name and Description. The example has hr-endpoint for name and AVA endpoint for HR application as the description.
Select the HR Group that you created in Step 3 from the dropdown list.
Under Application Domain, provide the public DNS name for your application and then select the public TLS certificate created and stored to the ACM. For example: hr.xxxxx.people.aws.dev.
1. Verified Access supports wildcard certificates, which means that you can use a wildcard certificate for all your endpoints, but it doesn’t support wildcard endpoints, which means you cannot have a single endpoint mapping to multiple hostnames.
For attachment type, select VPC.
Select the Security group to be used for the endpoint. Traffic from the endpoint that enters your load balancer is associated with this security group.
For Endpoint type, choose Load balancer. Select the HTTP, port 80, load balancer ARN, and subnet.
Choose Create Verified Access Endpoint.

Repeat the same steps to create an endpoint for the HR application.

It can take a few minutes for the endpoint to become active. Your endpoints are active when you see Active in the Status field.

Figure 10: The HR application endpoint has been created

Create Verified Access policies using trust data from user and device trust providers

Before you make the application available on your public domain for your users, define the access policies for your applications.

Verified Access policies are written in Cedar, an AWS policy language. Review the Verified Access policies documentation for details on policy syntax. The context that is available to use in policies varies based on the trust provider. You can review Trust data from trust providers to learn more about the available trust data for supported trust providers.

To Create or modify group level policy:

You now need to define an access policy for your applications at the group level.

In the Amazon VPC console, select Verified Access groups.
Select one of the groups you created earlier for your application.
From Actions, choose Modify Verified Access Group Policy.

In the policy document, provide the following policy:

permit(principal,action,resource)
when {
    context.idcpolicy.groups has "d6e20264-4081-7021-48df-def4276a19fe" &&
    context.idcpolicy.user.email.address like "*@example.com" &&
    context has "jamfpolicy" &&
    context.jamfpolicy has "risk" &&
    ["LOW","SECURE"].contains(context.jamfpolicy.risk)
};

Choose Modify Verified Access group policy.

The policy checks for claims received from the user trust provider (IAM Identity Center) and the device trust provider (Jamf). Based on these claims, it makes a decision whether the user is authorized to access the application. In the preceding policy, you check whether the user who is trying to access this application belongs to a certain group and has an email ending with example.com in IAM Identity Center by referencing to the idcpolicy context, which you defined while creating the user trust provider. Similarly, you use the jamfpolicy to reference the context coming from Jamf to validate whether the device used for accessing this application is secure or not. If access criteria aren’t matched, the user will receive a 403 Unauthorized error.

You need to repeat the preceding steps for the other group, defining the access policy with relevant group ID and claims for the application.

Amazon Route 53 configuration

After you complete your Verified Access setup and have defined your access policies, you will make your application public for your users to be able to access from anywhere, without a VPN and in a secure manner. For that, you will update your Amazon Route 53 records with the endpoints you created in Step 4: Create Verified Access endpoints.

In the Amazon VPC console, select Verified Access endpoints.
Select one of the endpoints you created earlier for your application.
From the Details section, make a note of the Endpoint domain. Repeat these two steps for the other endpoint as well and make a note of the endpoint domain.
Go to the Amazon Route53 console and in your hosted zone, choose Click Record.
Provide a Record name. This is the subdomain your users will use to access the application.
For Record type select CNAME.
In the Value section, provide the endpoint domain that you copied from Verified Access endpoints. Leave everything else as the default settings and choose Create records. Repeat these steps for the other endpoint and provide the relevant subdomain and value to the record.

Figure 11: The Route 53 record has been created

And that’s it. You have finished integrating Jamf Trust and Jamf Pro with Verified Access, and your users can now access their applications using the above CNAMES from their managed computers.

Test the solution

To test, use your browser (Firefox or Chrome) on one of your Jamf managed computers with the Verified Access extension installed to access one or both applications. The user will first be directed to the IAM Identity Center sign-in screen to sign in to the application. Then Verified Access will evaluate the user and the device posture before either granting or denying access to the user.

Figure 12: Access has been granted to the user based on identity and device posture

If the user meets the requirements, they will be presented with the application page. If the user doesn’t meet the requirements, they will receive a 403 Unauthorized error.

Figure 13: Access has been denied to the user based on identity and device posture

Troubleshooting on EC2 Mac

During testing or later, if your users receive a 403 Unauthorized error or the Verified Access extension isn’t forwarding the request, use the following steps to verify the browser extension being used and installed on the device is correct.

To verify the extension using Google Chrome:

Verify that the browser extension is installed and is the latest version. If not, update the browser extension.
Verify that Jamf Trust is installed and your device has the corresponding profiles for Jamf Trust. If not, install Jamf Trust and push the Jamf Trust profile to the device.
If the problem persists, verify your local Jamf JSON configuration file and validate that the Chrome extension ID is correct. Follow these steps:
1. Go to Chrome and select Manage Extensions.
2. Enable Developer mode.
3. Check the value of ID for your installed Verified Access browser extension.
4. Open your terminal.
5. Use the following command to change your directory to /Library/Google/Chrome/NativeMessagingHosts
```
cd /Library/Google/Chrome/NativeMessagingHosts
```
6. Verify that the value for chrome-extension matches the ID of the installed browser extension.

To verify the extension using Firefox:

Verify that the browser extension is installed and is the latest version. If not, update the browser extension.
Verify that Jamf Trust is installed and your device has the corresponding profiles for Jamf Trust. If not, install Jamf Trust and push the Jamf Trust profile to the device.
If the problem persists, verify your local Jamf JSON configuration file and validate that it points to the correct Verified Access Firefox browser extension deployment.
1. Open your terminal.
2. Use the following command to change your directory to /Library/Application\ Support/Mozilla/NativeMessagingHosts:
```
cd /Library/Application\ Support/Mozilla/NativeMessagingHosts
```
3. Verify that the value for allowed_extensions is pointing to verified-access@amazonaws.

Conclusion

In this blog post, you learned how to use additional claims from a device trust provider such as Jamf in addition to user identity to provide access to corporate applications with AWS Verified Access. The access policies defined at Verified Access level consider the user identity and the device posture to determine and grant access to a user. Verified Access aligns with the principles of Zero Trust and evaluates each access request at scale in real time for user identity and device posture. Verified Access helps you keep your applications hosted in AWS securely without relying solely on a network perimeter for protection. To get started with Verified Access, visit the Amazon VPC console.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

AWS Security Blog