Secure Okta SaaS Applications with Banyan

Use federation capabilities in Okta to enforce Banyan Policies on and enable passwordless for your SaaS applications

  • Updated on May 09, 2022
  • 15 minutes to read
  • Contributors

This article describes features that are only available in the Banyan Business edition and Banyan Enterprise edition.

Overview

This guide details the steps required to set up Okta with Banyan to enable policy enforcement and passwordless authentication for any SaaS application.

How It Works

In the IDP-routed authentication flow, you configure your Okta to federate authentication requests to Banyan. Banyan provides policy enforcement and can also perform passwordless authentication.

Prerequisites

Before proceeding through the Steps sections below, please ensure you have:

Steps

1. Create a Web Policy

To learn more about how policies work, see Policies

1.1 Navigate to Secure Access > Policies > + Create Policy and select Web Policy.

1.2 Enter a policy name and description.

1.3 Set the recommended policy attributes

  • Role : ANY
    • Specific user and device assignment for SaaS applications is typically done at the IDP.
  • TrustLevel: High or Medium if all devices will be registered with the Banyan App

1.4 Click Create Policy.

2. Create a SaaS Application in Banyan

Organizations can create one IDP Routed SaaS App for all Okta applications or create multiple IDP Routed SaaS Apps for groups of applications such as High Security vs Medium Security.

2.1 Navigate to Manage Services > SaaS Applications > PUBLISH SAAS APPLICATION.

2.2 Select IDP Routed for Okta to route to Banyan

2.3 Name the SaaS App and verify the IDP redirect url.

2.4 Attach a web policy (Step 1.4) and set enforcement mode.

2.5 Click Register.

The next screen will give you the details you need to set up Okta to use Banyan to enforce your policies.

3. Add Banyan as an Identity Provider in Okta

3.1 Navigate to Security > Identity Providers > Add Identity Provider.

3.2 Select Add OpenID Connect IdP and click Next.

3.3 Name the Identity Provider Banyan Policy Engine and enter the config field values you obtained in Step 2.5 above.

4. Add a Banyan Fallback Routing Rule

Since all Okta authentication traffic can eventually be federated, you need to ensure that flows involving the Banyan Device Registration App Integration bypass federation so that users are not forced into infinite redirect loops.

4.1 Navigate from Security > Identity Providers > Routing Rules.

4.2 Add a Routing Rule called Banyan Fallback Routing.

4.3 Select the Banyan Device Registration SaaS Application.

4.4 Select Okta as the identity provider.

4.5 Ensure the routing rule has been activated.

5. Route Specific Okta Applications to Banyan

This step will only protect SP-initiated flows for certain applications. When ready, it is recommended to Protecting All Okta Applications and the Okta Catalog.

5.1 Navigate from Security > Identity Providers > Routing Rules.

5.2 Add a routing rule called Banyan Policy Engine Routing, and select the SaaS applications that you wish to secure with Banyan Policies.

5.3 Select the Banyan Policy Engine identity provider you created in Step 3.

5.4 Select the specific applications that you wish to secure with Banyan.

Warning Do not select “Any application” when you set up the routing rule here until you are ready to Protecting All Okta Applications and the Okta Catalog, as it may result in an infinite redirect loop.

5.5 Ensure that the routing rule has been activated.

6. Enable Passwordless

Passwordless is recommended to provide an optimal user experience when accessing applications on Banyan registered devices. If Passwordless is not enabled, end users will default to Okta’s authentication methods.

Passwordless authentication with Banyan leverages the fact that the trusted Device Certificate includes the user’s email address in the UserPrincipalName SAN extension field.

When passwordless is enabled, the device certificate that is presented during device trust will be used to extract the user who is attempting to authenticate. The identified user will be issued a TrustToken without requiring username and password. The user will then proceed with Okta’s authentication configurations for the user selected application

6.1 Edit the existing Okta SaaS application

6.2 Enable Passwordless Authentication

Summary of Routing Rules

Now, all authentication traffic for specific SaaS applications is routed to Banyan for policy enforcement. A summary of your Okta Routing Rules is as follows:

Routing Rule Applications to Route IDP to Route to
1. Banyan Fallback Routing Banyan Device Registration Provider Okta
2. Banyan Policy Engine Routing Specific Applications Banyan Policy Engine
3. Default Rule Any Application Okta


Protecting All Okta Applications and the Okta Catalog

Once you have familiarized yourself with the integration, it is recommended to ensure requests to any Okta applications directly or via the Okta Catalog go through Banyan policy checks.

1. Confirm Banyan Web Policy attributes

  • A policy in Enforcement will not allow any fallback for devices that don’t meet trust levels in your policy.
  • A policy in Permissive will allow for a fallback for users that are not registered.

2. Navigate from Security > Identity Providers > Routing Rules.

3. Update the Banyan Policy Engine Routing Rule to route all application traffic.

Now, all Okta authentication traffic is routed to Banyan for policy enforcement. A summary of your Okta Routing Rules is as follows:

Routing Rule Applications to Route IDP to Route to
1. Banyan Fallback Routing Banyan Device Registration Provider Okta
2. Banyan Policy Engine Routing Any Application Banyan Policy Engine
3. Default Rule Any Application Okta


Additional Configurations

Phased Roll out Solution Guide

Admins typically need to phase the roll-out of Banyan device policies for Okta applications. Banyan provides 2 capabilities that support a phased roll out - (1) support for unregistered devices and (2) the ability to set up policies in permissive mode.

Review a prescriptive roll-out process in our Solution Guide on enforcing device trust for Okta applications so you can get visibility into how your Banyan rollout is progressing without blocking users and devices immediately.

Exempting Specific Users from Banyan Policies

In the setup above, all users will get routed to Banyan for policy enforcement. You can use leverage the same Okta Routing Rules to exempt specific types of users from Banyan policies. We recommend using a user’s login attributes (not network zones via Source IP address matching or device platorm via browser sniffing) to exempt users.

1. Add a routing rule called Banyan Exempt Users Routing, and set the match rules based on the attributes of the users to exempt. Select Okta as the identity provider.

2. Place this routing rule above the Banyan Policy Engine Routing rule

The summary of your Okta Routing Rules is then as follows:

Routing Rule Applications to Route IDP to Route to
1. Banyan Fallback Routing Banyan Device Registration Provider Okta
2. Banyan Exempt Users Routing Any Application Okta
3. Banyan Policy Engine Routing Any Application Banyan Policy Engine
4. Default Rule Any Application Okta

Exempting Non-SaaS Applications from Passwordless

By default, enabling passwordless for Okta will apply to all Banyan service access flows. To exempt Hosted Websites and Banyan App authentication for Infrastructure Services and Service Tunnels from leveraging passwordless, complete the following steps:

1. Edit the Banyan Fallback Routing rule in Okta

2. Add the Banyan TrustProvider application to the rule and Save.

Now, all Hosted Websites and Banyan App authentication for Infrastructure Services and Service Tunnels will not go through Banyan Passwordless and leverage Okta for authentication. A summary of your Okta Routing Rules is as follows:

Routing Rule Applications to Route IDP to Route to
1. Banyan Fallback Routing Banyan Device Registration Provider, Banyan TrustProvider Okta
2. Banyan Policy Engine Routing Any Application Banyan Policy Engine
3. Default Rule Any Application Okta

IDP-based Sign On Policy

When using Authentication Sign On rules (specifically MFA rules) in Okta with third-party IDPs via routing rules , Okta creates an MFA challenge for each IDP in the authentication chain. This may sometimes result in end users being prompted twice for MFA challenges.

To avoid this undesired end user experience, Okta has an early-access feature that allows the Okta admin to specify which IDP the Authentication Sign On rule(s) will apply to, such as “Okta”.

To configure this early access feature:

1. Navigate from Security > Authentication > Sign On.

2. Edit an existing sign-on policy, and then add a new rule.

3. Locate the field AND Identity Provider, and then select Okta.

If you do not see the AND Identity Provider option, you’ll need to file a ticket to Okta Support to “Enable feature - IdP-based sign on policy”. Okta Support will typically enable this feature for you within a few hours.