Device Trust Verification

Leverage SonicWall Cloud Secure Edge (CSE) app to establish Device Trust on mobile devices as well as apps whose authentication WebViews are unable to use the CSE device certificate

  • Updated on May 31, 2024

Overview

SonicWall Cloud Secure Edge (CSE) zero-trust security policies rely on a device certificate to authenticate the device from which an end user is accessing a Service. On desktops, the CSE certificates are stored securely in the Device Keychain on macOS and Certificate Store on Windows/Linux. CSE’s TrustProvider component performs the Mutual Auth TLS handshake to receive the device certificate from the device, extracts the device Serial Number from the device certificate, and uses the Serial Number to associate the request with Roles and Trust Level, and then enforce Policy.

There are certain cases in which CSE’s TrustProvider component is not able to get the certificate directly from the browser. Device Trust Verification brokers these workflows to ensure zero-trust security policies are evaluated in all scenarios. The two most common workflows for Device Trust Verification are the following:

1. Accessing services on mobile

CSE’s mobile registration flow stores the device certificate in the mobile application keychain. This allows for an optimized onboarding and service access experience for end users. Since CSE cannot validate the device certificate directly from the browser, Device Trust Verification leverages the CSE mobile app as a broker for device trust.

2. Sandboxed apps

CSE’s policies work seamlessly for browser-based access because web browsers can use the device certificate stored the Device Keychain consistently. However, many native applications on iOS/Android and even macOS/Windows use embedded web browsers, called WebViews, for authentication. The WebViews often do not have access to the device certificate on the device and cannot perform the Mutual Auth TLS handshake with CSE’s TrustProvider component. We refer to these types of apps as native “sandboxed apps” because their authentication WebView it not permitted by the OS to leave its “sandbox” to use the device certificate from the keychain.

Since CSE does not receive a device certificate from sandboxed apps, it is unable to associate the request with a specific device, even if the app (desktop or mobile) is installed on that device and a device certificate is present in the Keychain. Therefore, CSE typically cannot enforce Device Roles and Trust Scoring based policies for such apps.

How It Works

When Device Trust Verification is enabled for a service, CSE’s TrustProvider uses an alternative authentication flow to account for mobile device and sandboxed applications.

Mobile

In this alternative authentication flow, the end user is automatically routed to the app for the Device Trust check. The app submits the CSE client certificate as well as the most up to date set of Trust Factors. If authorization is successful, the end user can flip back to the browser or native app they were attempting to access and they will automatically proceed to the IDP authentication step.

If, for any reason, the browser does not redirect to the app, the end user can select the “Verify with Banyan” button to manually kick off the flow.

Sandboxed apps on desktop

The flow for sandboxed apps on desktop will be enhanced to resemble the mobile flow above in an upcoming release.

In this modified authentication flow, the end user is presented with a challenge code when attempting to access a CSE-protected service from a sandboxed app.

The end user must copy the challenge code and submit it via the Device Trust Verification tab in their app (desktop or mobile) to verify the device.

After submitting the challenge code and verifying their device, the end user returns to the sandboxed app to authenticate with the IDP and access the CSE-protected service. CSE’s Device Trust Verification capability allows Device Roles and Trust Scoring based policies for sandboxed apps.

Device Trust Verification Flow

The Device Trust Verification flow is used for mobile devices and sandboxed applications, as well as to support Unregistered Devices. The flow is depicted below:

Once you enable Device Trust Verification for sandboxed apps, the settings entered under Allow Unregistered Devices to Receive an HTTP Response, which allow you to provide a customized error message to Unregistered Devices, will no longer work. Instead, all requests from Unregistered Devices will receive the Device Trust Verification challenge and may fail the challenge-response mechanism. This will be fixed in an upcoming release.

Disable Device Trust Verification at the Organization-level

Device Trust Verification is not enabled by default; it needs to be enabled to support mobile devices. If you have org-wide Device Trust Verification enabled and you want to disable it, navigate from Settings > Configuration tab> Unregistered Devices, and then de-select the toggle under Enable Org Wide Device Trust Verification.

The Enable Org Wide Device Trust Verification switch is de-selected in the image above.

Disable Device Trust Verification at the Service-level

When Device Trust Verification is enabled for an organization, it is also enabled on all services in the organization.

However, some organizations may disable Device Trust Verification if the application is not sandboxed or if mobile devices will not be accessing it. Disabling Device Trust Verification will bypass the Device Verification fallback step (in the flow above) and proceed to the Unregistered Devices check.

To disable Device Trust Verification for a SaaS App or Hosted Service, navigate to the Advanced Configuration section of the service and select the Suppress Device Verification switch.

The Suppress Device Verification switch is selected in the image above.

Can’t find what you’re looking for?

We’re happy to help. Contact our team.