• Introduction
  • Use Case
• Steps
  • 1. Enable Unregistered Devices
  • 2. Create a SaaS Application Policy in CSE
  • 3. Create a SaaS Application in CSE
  • 4. Route specific Okta apps to CSE for Device Trust
  • 5. Route All Okta apps to CSE for Device Trust
  • 6. Enforce Device Trust
  • (Optional) Multiple Security Policies for Applications
• Summary
  • Solution

Introduction

In this guide you’ll learn how to enable the Cloud Secure Edge’s (CSE) Device Trust capabilities for SaaS apps in Okta. SonicWall supports a phased roll out that provides high visibility and a great end-user experience.

Use Case

Leverage this solution guide to accomplish the following:

• Use SonicWall to secure SaaS apps in Okta in a phased manner with low user impact
• Obtain visibility into which users/devices will be blocked when you enforce CSE policies
• Set up multiple policies for groups of SaaS applications

Steps

1. Enable Unregistered Devices

Allow unregistered devices will allow visibility into how your CSE app rollout is progressing without blocking users and devices immediately. You will be able to see which users are leveraging a CSE registered devices and which users are using devices without CSE on them.

1) Add the 0.0.0.0/0 CIDR range to account for all devices.

2) Select Update

2. Create a SaaS Application Policy in CSE

You will create a SaaS app policy in CSE for your Okta apps.

1) Create a user Role that includes users accessing SaaS applications.

2) Create a Web Policy that includes your role and trust score requirements

3. Create a SaaS Application in CSE

You will create an IDP Routed SaaS app in CSE that will link to an Identity Provider in Okta. The policy created in step 2 will be attached and the enforcement mode will be set to “Permissive” so users are not blocked until they have had time to register with the app.

1) Follow this step to create a SaaS Application in CSE

2) Ensure the Enforcement Mode for the policy is set to Permissive

4. Route specific Okta apps to CSE for Device Trust

This step will only protect SP-initiated flows for certain applications and is only recommended for testing purposes before routing all Okta application traffic.

Begin by routing a few applications to CSE to start your roll out. This will give you a good sense of how your policies are performing before you proceed to Step 5.

1) Add CSE as an Identity Provider in Okta

2) Route Specific Applications to CSE

3) Monitor Unregistered Devices

The unregistered device list view will populate with users who are accessing Okta applications from devices that do not have the CSE (formerly Banyan) certificate.

As more users download and register with the app, this list will decrease and you’ll be able to gauge who may be impacted when a policy goes into enforcement.

5. Route All Okta apps to CSE for Device Trust

Once you are comfortable with your policies, you can now route all applications to CSE.

The CSE SaaS app policy is still in Permissive mode and unregistered devices are still allowed. Anyone that does not meet policy requirements will still be able to access their Okta applications.

1) Follow the steps to protecting all Okta applications and the Okta catalog

2) Continue monitoring Unregistered Devices

6. Enforce Device Trust

Once you are confident that most of your users have registered with the CSE app and are meeting your policy requirements, it is now time to move the policy into enforcement. This will ensure only registered, trusted devices can access Okta SaaS apps.

1) Set Policy from Step 2 to “Enforcing”

2) Disable Unregistered Devices

• Remove “0.0.0.0/0” CIDR Range

(Optional) Multiple Security Policies for Applications

There may be scenarios where you want to have different policies for different groups of applications. This is supported by creating multiple Identity Providers in Okta tied to multiple SaaS apps in CSE.

This example shows how to create multiple policies for High Security vs Medium Security applications

1) Create two SaaS apps in CSE with different policies

2) Create a routing rule for Medium Security applications

3) Create a routing rule for High Security applications

In order to protect workflows where a user accesses an application from the Okta catalog, you will need to treat the Okta Catalog as a High Security application.

Summary

With these steps, we have provided a way securely roll out CSE device policies for Okta SaaS applications with low user impact.

Solution

We addressed the use cases above in the following ways:

1) Provided a way for a phased rollout of CSE device policies onto Okta SaaS applications while also allowing a fall back for devices that have not been registered yet or do not meet trust score Requirements.

2) Provided visibility into the devices accessing SaaS applications on unregistered devices, further helping you gauge your impact of moving a policy into enforcement.

3) Provided a way to set different policies for groups of applications or users.