SSL Orchestrator Advanced Use Cases: Fun with SaaS Tenant Isolation

Introduction

Introduced in SSL Orchestrator 10.1, you can now seemlessly integrate Microsoft Office 365 Tenant Restrictions as a service function in the decrypted service chain. Before I go any further, you may be asking, what exactly are Tenant Restrictions? And why would I want to use them? Well, I'm so glad you asked. 

Think of a tenant restriction as a way to isolate a tenant (i.e., a set of enterprise accounts) on a SaaS platform. This is super useful for SaaS resources like Office 365, where your enterprise users will have corporate access to Office 365, but may also have their own personal O365 accounts, or accounts with another corporate entity. An Office 365 Tenant Restriction essentially prevents users from accessing any O365 accounts other than those specifically allowed. Most important, a tenant restriction is a really good way to prevent some forms of data exfiltration - i.e., by preventing users from saving proprietary information to a personal or other non-sanctioned Office 365 account.

A tenant restriction essentially works by injecting one or more HTTP headers into an HTTP request for a specific set of request URLs, and enabling this feature in SSL Orchestrator 10.1 is super easy. You just create the service object, apply that service to a service chain, and put that service chain in the path of decrypted traffic. It's important to highlight here that injecting an HTTP header requires decrypted access to the traffic, so your SSL Orchestrator policy configuration must put this in a decrypted (intercept) path. To give you a quick example, for Office 365, you'll look for the following three request URLs:

  • "login.microsoftonline.com"
  • "login.microsoft.com"
  • "login.windows.net"

And if you see one of these, you'll inject the following two headers:

  • "Restrict-Access-To-Tenants" "<permitted-tenant-list>"
  • "Restrict-Access-Context" "<directory-id>" 

The above is all described in great and glorious detail here: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/tenant-restrictions.

Okay, so now that we've established what it is, and how it works, we can now get to the FUN part of this article. As it turns out, there are actually a few SaaS applications that support "tenant isolation", and they all do so in more or less the same way - inject one or more HTTP headers for a specified set of URLs. The common ones include:

  • Webex
  • Google G-Suite
  • Dropbox
  • Youtube
  • Slack

I'm sure there are more out there, but the above are what we'll focus on here. Let's see exactly how to set this up.

SSL Orchestrator Advanced Use Case: Fun with SaaS Tenant Isolation

The basic idea is to perform the following three steps:

  • Deploy Office 365 Tenant Restrictions in SSL Orchestrator 10.1
  • Replace the iRule that the service generates with a new iRule
  • Configure that iRule with the SaaS tenant isolation values that you require

Step 1: Deploy Office 365 Tenant Restrictions in SSL Orchestrator 10.1

Starting in SSL Orchestrator 10.1, in the UI go to Services and click the Add button. Navigate to the F5 tab, click on "Office 365 Tenant Restrictions" and then hit the Add button. You won't actually be using the iRule that this service creates, so put anything you want into the two required header fields and click Save & Next. On the subsequent Service Chains List page, select or create a service chain and add this new service to that service chain. Click Save & Next. At this point, just make sure this service chain is assigned to a security policy rule that intercepts (decrypts) traffic. Deploy and move on to the next step.

Step 2: Replace the iRule that the service generates with a new iRule

Head over to the following Github repo to get the new iRule: https://github.com/f5devcentral/sslo-script-tools/tree/main/saas-tenant-isolation. In the BIG-IP UI, under Local Traffic, iRules, create a new iRule and paste the content there. Now back in the SSL Orchestrator UI, go to the Services tab, select your Office 365 Tenant Restrictions service to edit, and then at the bottom of the page, replace the selected iRule with your new tenant isolation iRule. Deploy and move on to the next step.

Step 3: Configure the new iRule with the SaaS tenant isolation values that you require

You're now going to need to make a few modifications to the new iRule. In the BIG-IP UI, under Local Traffic, iRules, click on your new tenant isolation iRule to edit. The iRule comes pre-built to support all of the aforementioned SaaS applications.

  • Step 3a: In the RULE_INIT section, there is a separate array defined for each SaaS application. Inside each array is the required tenant isolation header(s) for that application. If you need to deploy tenant isolation headers for a given SaaS application, replace the "enter-value-here" string next to each header name with the required value. I've provided additional references below to help with those values.
  • Step 3b: At the bottom of the RULE_INIT section, there are a set of static variables that enable or disable header injection for each SaaS application. To enable, set the value to 1. Otherwise to disable set the value to 0.

That's basically it. If you've configured the header values correctly, and the service is in the direct path of decrypted outbound traffic through SSL Orchestrator, then the iRule should be doing it's job to prevent data exfiltration in your environment. Good job!

Summary

With an iRule and just a few configuration changes we have been able to implement a capability on top of SSL Orchestrator to extend the built-in Office 365 Tenant Restrictions service to support a set of additional SaaS applications. This flexibility is just one of the many interesting benefits of and SSL Orchestrator solution.

Additional Resources

As previously mentioned, there are more than just the described SaaS applications out in the wild that support tenant isolation, but these are the most common. If you know of any that might be useful to add, please let me know. Below is a quick reference for each of the included SaaS applications and the required match-on and send values.

Office 365

_________________________________________________

Webex

_________________________________________________

Google / G-Suite

  • Ref: https://support.google.com/a/answer/1668854?hl=en
  • Match on:
    • *.google.com
    • *.googleusercontent.com
    • *.gstatic.com
  • Send:
    • X-GooGApps-Allowed-Domains = <comma separated list of allowed domains>
    • Ex. X-GoogApps-Allowed-Domains: mydomain1.com, mydomain2.com

 _________________________________________________

Dropbox

 _________________________________________________

Youtube

  • Ref: https://support.google.com/a/answer/6214622?hl=en
  • Match on:
  • Send:
    • YouTube-Restrict =
      • Strict. Provides access to a limited collection of video content. This is the most restricted mode.
      • Moderate. Provides some restricted access but is less strict than Strict mode. Moderate mode allows users to access a larger collection of video content.

_________________________________________________

Slack

 

Published Oct 31, 2022
Version 1.0
BIG-IP SSL Orchestrator
security
series-ssl-orchestrator-advanced-use-cases
SSL Orchestrator
sslo
tls

Was this article helpful?

No CommentsBe the first to comment