Leverage F5 BIG-IP APM and Azure AD Conditional Access Easy button
Integrating F5 BIG-IP APM’s Identity Aware Proxy (IAP) with Microsoft EntraID (Previously called AzureAD) Conditional Access enables fine-grained, adaptable, zero trust access to any application, regardless of location and authentication method, with continuous monitoring and verification.
Zero Trust building blocks - Leverage Microsoft Intune endpoint Compliance with F5 BIG-IP APM Access
Use case summary Let's walk through a real life scenario, we have company A that's building its Zero Trust strategy and of course it will be great to make use of existing solutions to reach our target. Microsoft Intune introduces a great source of intelligence and compliance enforcement for endpoints, combined with F5 BIG-IP Access Policy Manager (APM) integrated with Microsoft EntraID (previously called AzureAD) this extends the enforcement to the endpoints accessing Company A resources whether it's a SAAS or locally hosted. Below is the flow of some use cases that leverage how F5 BIG-IP APM and Microsoft Intune pave the way to achieve Zero Trust strategy. We've an endpoint Managed by Microsoft Intune. Microsoft Intune contains device compliance policy to determine the conditions at which the machine to be considered compliant and the configuration profile determine the configurations for specific applications in our case (F5 Access VPN). We have the following use cases, User tries to access web application through F5 BIG-IP APM, BIG-IP is already integrated with Microsoft Intune and Microsoft EntraID (previously called AzureAD). F5 BIG-IP APM acts as SP, that directs user request to Microsoft EntraID (previously called AzureAD) for authentication and compliance check. If the user successfully authenticate and pass compliance policy, user will be redirected back to the application with SAML assertion response otherwise the user will be denied to acces. A demo was created by our awesome Access guru Matt_Dierick User tries to use SSL VPN to access corporate resources, User click on F5 Access VPN connection pushed to the endpoint via configuration profile at Microsoft Intune. User selects the proper authentication method (Username&Password, Smart Card or Certificate based Authentication). Once user successfully authenticate and pass compliance check, a temporary certificate is pushed to the machine. The temporary certificate is used to authenticate with F5 BIG-IP APM and then the user is granted access to SSL VPN connection. A demo was created for this use case as well by our awesome Access guru Matt_Dierick , as Microsoft Intune portal got updated, we may now perform the endpoint management related tasks through endpoint.microsoft.com portal instead of portal.azure.com, make sure to follow Microsoft documentations for any new updates. Conclusion In conclusion to the highlighted use cases, we can see that we can make use of existing solutions and extend their capabilities with the ease of integration to acheive our organization Zero Trust strategy. F5 BIG-IP in general allows the organization to decouple client side connection from server side, which simplifies further services integration to boost organization security posture. F5 BIG-IP APM allows us to integrate with different parties to extend their capabilties whether they endpoint compliance, risk factor or IDaaS to use such insights for securing application or network access. In addition to corporate related secure access, if we have customers accessing applications and need integration with Google or other Open ID Connect (OIDC) provider, you can make use of F5 BIG-IP APM OIDC integration to that 3rd party for customers' access. Additional resources Configuring Access Policy Manager for MDM applications BIG-IP Access Policy Manager: Third-Party Integration OAuth and OpenID Connect - Made easy with Access Guided Configurations templatesBIG-IP for Scalable App Delivery & Security in Hybrid Environments
Scope: As enterprises deploy multiple instances of the same applications across diverse infrastructure platforms such as VMware, OpenShift, Nutanix, and public cloud environments and across geographically distributed locations to support redundancy and facilitate seamless migration, they face increasing challenges in ensuring consistent performance, centralized security, and operational visibility. The complexity of managing distributed application traffic, enforcing uniform security policies, and maintaining high availability across hybrid environments introduces significant operational overhead and risk, hindering agility and scalability. F5 BIG-IP Application Delivery and Security address this challenge by providing a unified, policy-driven approach to manage secure workloads across hybrid multi-cloud environments. It can be used to scale up application services on existing infrastructure or with new business models. Introduction: This article highlights how F5 BIG-IP deploys identical application workloads across multiple environments. This ensur high availability, seamless traffic management, and consistent performance. By supporting smooth workload transitions and zero-downtime deployments, F5 helps organizations maintain reliable, secure, and scalable applications. From a business perspective, it enhances operational agility, supports growing traffic demands, reduces risk during updates, and ultimately delivers a reliable, secure, and high-performance application experience that meets customer expectations and drives growth. This use case covers a typical enterprise setup with the following environments: VMware (On-Premises) Nutanix (On-Premises) Google Cloud Platform (GCP) Architecture: As illustrated in the diagram, when new application workloads are provisioned across environments such as AWS, GCP, VMware (on-prem), Nutanix (on-prem & VMware) BIG-IP ensures seamless integration with existing services. Platforms Supported Environments VMware On-Prem, GCP, Azure Nutanix On-Prem, AWS, Azure This article outlines the deployment in VMware platform. For deployment in other platforms like Nutanix and GCP, refer the detailed guide below. F5 Scalable Enterprise Workload Deployments Complete Guide Scalable Enterprise Workload Deployment Across Hybrid Environments Enterprise applications are deployed smoothly across multiple environments to address diverse customer needs. With F5’s advanced Application Delivery and Security features, organizations can ensure consistent performance, high availability, and robust protection across all deployment platforms. F5 provides a unified and secure application experience across cloud, on-premises, and virtualized environments. Workload Distribution Across Environments Workloads are distributed across the following environments: VMware: App A & App B OpenShift: App B Nutanix: App B & App C → VMware: Add App C → OpenShift: Add App A & App C → Nutanix: Add App A Applications being used: A → Juice Shop (Vulnerable web app for security testing) B → DVWA (Damn Vulnerable Web Application) C → Mutillidae Initial Infrastructure: & B, Nutanix: App B &C, GCP: App B. VMware: In the VMware on-premises environment, Applications A and B are deployed and connected to two separate load balancers. This forms the existing infrastructure. These applications are actively serving user traffic with delivery and security managed by BIG-IP. Web Application Firewall (WAF) is enabled, which will prevent any malicious threats. The corresponding logs can be found under BIG-IP > Security > Event Logs Note: This initial deployment infrastructure has also been implemented on Nutanix and GCP. For the full details, please consult the complete guide here Adding additional workloads: To demonstrate BIG-IP’s ability to support evolving enterprise demands, we will introduce new workloads across all environments. This will validate its seamless integration, consistent security enforcement, and support for continuous delivery across hybrid infrastructures. VMware: Let us add additional application-3 (mutillidae) to the VMware on-premises environment. Try to access the application through BIG-IP virtual server. Apply the WAF policy to the newly created virtual server, then verify the same by simulating malicious attacks. Nutanix: The use case described for VMware is equally applicable and supported when deploying BIG-IP on Nutanix Bare Metal as well as Nutanix on VMware. For demonstration purposes, the Nutanix Community Edition hypervisor is booted as a virtual machine within VMware. Inside this hypervisor, a new virtual machine is created and provisioned using the BIG-IP image downloaded from the F5 Downloads portal. Once the BIG-IP instance is online, an additional VM hosting the application workload is deployed. This application VM is then associated with a BIG-IP virtual server, ensuring that the application remains isolated and protected from direct external exposure. GCP (Google Cloud Platform): The use case discussed above for VMware is also applicable and supported when deploying BIG-IP on public cloud platforms such as Azure, AWS, and GCP. For demonstration purposes, GCP is selected as the cloud environment for deploying BIG-IP. Within the same project where the BIG-IP instance is provisioned, an additional virtual machine hosting application workloads is deployed and associated with the BIG-IP virtual server. This setup ensures that the application workloads remain protected behind BIG-IP, preventing direct external exposure. Key Resources: Please refer to the detailed guide below, which outlines the deployment of Nutanix on VMware and GCP, and demonstrates how BIG-IP delivers consistent security, traffic management, and application delivery across hybrid environments. F5 Scalable Enterprise Workload Deployments Complete Guide Conclusion: This demonstration clearly illustrates that BIG-IP’s Application Delivery and Security capabilities offer a robust, scalable, and consistent solution across both multi-cloud and on-premises environments. By deploying BIG-IP across diverse platforms, organizations can achieve uniform application security, while maintaining reliable connectivity, strong encryption, and comprehensive protection for both modern and legacy workloads. This unified approach allows businesses to seamlessly scale infrastructure and address evolving user demands without sacrificing performance, availability, or security. With BIG-IP, enterprises can confidently deliver applications with resilience and speed, while maintaining centralized control and policy enforcement across heterogeneous environments. Ultimately, BIG-IP empowers organizations to simplify operations, standardize security, and accelerate digital transformation across any environment. References: F5 Application Delivery and Security Platform BIG-IP Data SheetHow I did it - "F5 BIG-IP Observability with Dynatrace and F5 Telemetry Streaming"
Welcome back to another edition of “How I Did It.” It’s been a while since we looked at observability… Oh wait, I just said that. Anyway, in this post I’ll walk through how I integrated F5 Telemetry Streaming with Dynatrace. To show the results, I’ve included sample dashboards that highlight how the ingested telemetry data can be visualized effectively. Let’s dive in before I repeat myself again.Automating ACMEv2 Certificate Management on BIG-IP
While we often associate and confuse Let's Encrypt with ACMEv2, the former is ultimately a consumer of the latter. The "Automated Certificate Management Environment" (ACME) protocol describes a system for automating the renewal of PKI certificates. The ACME protocol can be used with public services like Let's Encrypt, but also with internal certificate management services. In this article we explore the more generic support of ACME (version 2) on the F5 BIG-IP.Service Extensions with SSL Orchestrator: Advanced Blocking Pages
Introduction Service Extensions are a new programmable capability in F5 BIG-IP SSL Orchestrator (as of F5 BIG-IP 17.0) that allow for customizable behaviors on decrypted HTTP traffic directly from within the Service Chain. In this article you will learn how to download, install, and configure the policy that enables the “Advanced Blocking Pages” Service Extension. What are Advanced Blocking Pages? Advanced Blocking Pages allow for easy customization of the block page as well as flexible policy options to trigger specific block pages. This Service Extension creates a Service that will return a block page when placed into a Service Chain. It can also apply the iRule logic to dynamically inject the contents of a blocking page. Deployment Prerequisites F5 BIG-IP version 17.1.x SSL Orchestrator version 11.1+ This article assumes you have an SSL Orchestrator configured with a Topology and Service Chain. Advanced Blocking Pages Service Extension Installation The information below is from the GitHub repository for the Advanced Blocking Pages Service Extension (click here for a direct link). It includes an installer to create all the necessary objects. Download the installer: curl -sk https://raw.githubusercontent.com/f5devcentral/sslo-service-extensions/refs/heads/main/advanced-blocking-pages/advanced-blocking-pages-installer.sh -o advanced-blocking-pages-installer.sh CLI output: Make the script executable: chmod +x advanced-blocking-pages-installer.sh CLI output: Export the BIG-IP username and password: export BIGUSER='admin:password' CLI output: Note: replace “password” with your actual BIG-IP admin password Run the script to create all the SaaS Tenant Isolation objects: ./advanced-blocking-pages-installer.sh CLI output: The installer creates a new Inspection Service named "ssloS_F5_Advanced-Blocking-Pages". Add this Inspection Service to any Service Chain that can receive decrypted HTTP traffic. Service Extension Services will only trigger on decrypted HTTP, so can be inserted into Service Chains that may also see TLS bypass traffic (not decrypted). SSL Orchestrator will simply bypass this Service for anything that is not decrypted HTTP. After following the steps above, the SSL Orchestrator screen should look like this: Customizing Functionality To customize the functionality of the Blocking Pages we’ll start by editing an iRule. Navigate to Local Traffic > iRules > iRule List Click on the iRule named “advanced-blocking-pages-rule” (you may need to expand the iRule List) To enable the Advanced Blocking Pages, set the value for “GLOBAL_BLOCK” from 0 to 1. Click Update. NOTE: We’ll go over the other customization options later in this article. Move the Advanced-Blocking-Pages Service to a Service Chain Go to the SSL Orchestrator Configuration screen Click Service Chains then Add NOTE: For testing purposes, it is recommended to create a new Service Chain and add the Advanced-Blocking-Page Service to it Give it a name, “AdvancedBlocking” in this example. Select the ssloS_F5_Advanced-Blocking-Pages Service and click the arrow to move it to the right Click Deploy Click OK Edit the Security Policy From the Configuration screen, select Security Policies then click the policy you want to edit, “L3_Outbound” in this example. Click Add to add a Rule Give the Rule a name, “BlockThreats” in this example Configure the Rule Conditions by selecting Category Lookup (All) Select the Categories you wish to Block by clicking in the “Click to select” field Select all Malware-related categories These are all the Malware-related categories: Advanced Malware Command and Control Advanced Malware Payloads Malicious Embedded Link Malicious Embedded iFrame Malicious Web Sites Mobile Malware You may want to consider adding the following Categories, too: Spyware and Adware Suspicious NOTE: For testing purposes, it would be safer to add a category like “Alcohol and Tobacco” to the above rule in order to test its efficacy. Set the Action to Allow (this is counterintuitive) Set the SSL Proxy Action to Intercept Set the Service Chain to the one created previously, “AdvancedBlocking” Click OK The Security Policy should look like this: Click Deploy Click Deploy Click OK Test the Advanced Blocking Page Assuming you have added the “Alcohol and Tobacco” Category to the Security Policy, go to a client computer and test it now. An attempt to view the Products page on www.marlboro.com results in the following: Note: remember to remove the “Alcohol and Tobacco” category from the Security Policy. Customizing the Blocking Page First, you need an html file to use as the custom Blocking Page. You can use a sample file from the GitHub repository. Expand the folder “blocking-page-samples” and click “blocking-page-sample1.html”. Click the Download button on the right. To Customize the Blocking Page, go to System > File Management > iFile List > Import Choose the Blocking Page sample file in your Downloads folder. Choose Overwrite Existing, then click Import. Test the Blocking Page again and it should look like the following: Injecting Dynamic Messages To inject a dynamic message in the block page, edit the “advanced-blocking-pages-rule” iRule. Find “set static::GLOBAL_BLOCK_MESSAGE” in the iRule and replace all the text within the quotation marks: Click Update when done Test the Blocking Page again and it should look like the following: Handling Server-Side Certificate Errors SSL Orchestrator can also be customized to handle different server-side certificate validation errors. To configure this, start by editing the SSL Configuration. Click the Edit icon Click Show Advanced Settings Near the bottom, set Expire Certificate Response and Untrusted Certificate Authority from Drop to Mask. Click Save & Next when done. The Mask option tells SSL Orchestrator to send a good/valid certificate to the client when these certificate errors occur. This allows a custom blocking page to be presented to the client. Click OK Click Deploy Click OK Next, edit the Interception Rule for this Topology Click the Edit icon In the Resources section near the bottom, move the “ssl-tls-verify-rule” from Available to Selected. Click Save & Next Click Deploy Click OK NOTE: The blocking page iRule (when GLOBAL_BLOCK is 0) will read this context array variable and trigger the blocking page if the certificate verification code is not ‘ok’. It also injects the verification code string into the page. You can test this using the site, https://badssl.com Under Certificate, try “expired” and “self-signed” Example of Expired Certificate: Example of Self-Signed Certificate: Handling Custom Blocking Page Triggers The included iRule is intentionally sparse to include the two primary blocking page use cases (global blocking and server-side certificate validation errors): when HTTP_REQUEST { if { $static::GLOBAL_BLOCK } { call GEN_BLOCK_PAGE ${static::GLOBAL_BLOCK_MESSAGE} event disable all } else { sharedvar ctx if { ( [info exists ctx(tlsverify)] ) and ( $ctx(tlsverify) ne "ok" ) } { call GEN_BLOCK_PAGE "This request has been blocked due to a server side TLS issue: <br /></br>[string toupper $ctx(tlsverify)]" event disable all } } } To customize this for additional triggers, add iRule logic inside the “else” block as required: if { some-condition } { call GEN_BLOCK_PAGE "message to send into blocking page `receive_msg` variable" event disable all } Conclusion SSL Orchestrator Advanced Blocking Pages allow for easy customization of the block page as well as flexible policy options to trigger specific block pages. Related Content Service Extensions with SSL Orchestrator SaaS Tenant Isolation Service Extensions with SSL Orchestrator User Coaching of AI Related Content SSL Orchestrator Service Extensions: DoH Guardian Office 365 Tenant Restrictions Introduction to BIG-IP SSL Orchestrator Integrating Security Solutions with F5 BIG-IP SSL OrchestratorAutomate Let's Encrypt Certificates on BIG-IP
To quote the evil emperor Zurg: "We meet again, for the last time!" It's hard to believe it's been six years since my first rodeo with Let's Encrypt and BIG-IP, but (uncompromised) timestamps don't lie. And maybe this won't be my last look at Let's Encrypt, but it will likely be the last time I do so as a standalone effort, which I'll come back to at the end of this article. The first project was a compilation of shell scripts and python scripts and config files and well, this is no different. But it's all updated to meet the acme protocol version requirements for Let's Encrypt. Here's a quick table to connect all the dots: Description What's Out What's In acme client letsencrypt.sh dehydrated python library f5-common-python bigrest BIG-IP functionality creating the SSL profile utilizing an iRule for the HTTP challenge The f5-common-python library has not been maintained or enhanced for at least a year now, and I have an affinity for the good work Leo did with bigrest and I enjoy using it. I opted not to carry the SSL profile configuration forward because that functionality is more app-specific than the certificates themselves. And finally, whereas my initial project used the DNS challenge with the name.com API, in this proof of concept I chose to use an iRule on the BIG-IP to serve the challenge for Let's Encrypt to perform validation against. Whereas my solution is new, the way Let's Encrypt works has not changed, so I've carried forward the process from my previous article that I've now archived. I'll defer to their how it works page for details, but basically the steps are: Define a list of domains you want to secure Your client reaches out to the Let’s Encrypt servers to initiate a challenge for those domains. The servers will issue an http or dns challenge based on your request You need to place a file on your web server or a txt record in the dns zone file with that challenge information The servers will validate your challenge information and notify you You will clean up your challenge files or txt records The servers will issue the certificate and certificate chain to you You now have the key, cert, and chain, and can deploy to your web servers or in our case, to the BIG-IP Before kicking off a validation and generation event, the client registers your account based on your settings in the config file. The files in this project are as follows: /etc/dehydrated/config # Dehydrated configuration file /etc/dehydrated/domains.txt # Domains to sign and generate certs for /etc/dehydrated/dehydrated # acme client /etc/dehydrated/challenge.irule # iRule configured and deployed to BIG-IP by the hook script /etc/dehydrated/hook_script.py # Python script called by dehydrated for special steps in the cert generation process # Environment Variables export F5_HOST=x.x.x.x export F5_USER=admin export F5_PASS=admin You add your domains to the domains.txt file (more work likely if signing a lot of domains, I tested the one I have access to). The dehydrated client, of course is required, and then the hook script that dehydrated interacts with to deploy challenges and certificates. I aptly named that hook_script.py. For my hook, I'm deploying a challenge iRule to be applied only during the challenge; it is modified each time specific to the challenge supplied from the Let's Encrypt service and is cleaned up after the challenge is tested. And finally, there are a few environment variables I set so the information is not in text files. You could also move these into a credential vault. So to recap, you first register your client, then you can kick off a challenge to generate and deploy certificates. On the client side, it looks like this: ./dehydrated --register --accept-terms ./dehydrated -c Now, for testing, make sure you use the Let's Encrypt staging service instead of production. And since I want to force action every request while testing, I run the second command a little differently: ./dehydrated -c --force --force-validation Depicted graphically, here are the moving parts for the http challenge issued by Let's Encrypt at the request of the dehydrated client, deployed to the F5 BIG-IP, and validated by the Let's Encrypt servers. The Let's Encrypt servers then generate and return certs to the dehydrated client, which then, via the hook script, deploys the certs and keys to the F5 BIG-IP to complete the process. And here's the output of the dehydrated client and hook script in action from the CLI: # ./dehydrated -c --force --force-validation # INFO: Using main config file /etc/dehydrated/config Processing example.com + Checking expire date of existing cert... + Valid till Jun 20 02:03:26 2022 GMT (Longer than 30 days). Ignoring because renew was forced! + Signing domains... + Generating private key... + Generating signing request... + Requesting new certificate order from CA... + Received 1 authorizations URLs from the CA + Handling authorization for example.com + A valid authorization has been found but will be ignored + 1 pending challenge(s) + Deploying challenge tokens... + (hook) Deploying Challenge + (hook) Challenge rule added to virtual. + Responding to challenge for example.com authorization... + Challenge is valid! + Cleaning challenge tokens... + (hook) Cleaning Challenge + (hook) Challenge rule removed from virtual. + Requesting certificate... + Checking certificate... + Done! + Creating fullchain.pem... + (hook) Deploying Certs + (hook) Existing Cert/Key updated in transaction. + Done! This results in a deployed certificate/key pair on the F5 BIG-IP, and is modified in a transaction for future updates. This proof of concept is on github in the f5devcentral org if you'd like to take a look. Before closing, however, I'd like to mention a couple things: This is an update to an existing solution from years ago. It works, but probably isn't the best way to automate today if you're just getting started and have already started pursuing a more modern approach to automation. A better path would be something like Ansible. On that note, there are several solutions you can take a look at, posted below in resources. Resources https://github.com/EquateTechnologies/dehydrated-bigip-ansible https://github.com/f5devcentral/ansible-bigip-letsencrypt-http01 https://github.com/s-archer/acme-ansible-f5 https://github.com/s-archer/terraform-modular/tree/master/lets_encrypt_module (Terraform instead of Ansible) https://community.f5.com/t5/technical-forum/let-s-encrypt-with-cloudflare-dns-and-f5-rest-api/m-p/292943 (Similar solution to mine, only slightly more robust with OCSP stapling, the DNS instead of HTTP challenge, and with bash instead of python)App Migration across Heterogeneous Environments using F5 Distributed Cloud
F5 XC helps in deploying Customer Edge (CE) on different cloud environment such as VMware, Nutanix, Red Hat Openshift (OCP), Azure, AWS, GCP and more. This helps in migration across on-prem and cloud platforms for easy of use and leverage the services of cloud platforms for migration.Service Extensions with SSL Orchestrator: SaaS Tenant Isolation
Introduction F5 BIG-IP SSL Orchestrator is a great solution for managing SaaS Tenant Isolation. It gives you granular control over access to external SaaS applications. Microsoft Office365, Webex, Dropbox, GitHub, and many other SaaS applications are supported. Service Extensions are a new programmable capability in the SSL Orchestrator Service Chain (as of BIG-IP 17.0) that allow for customizable behaviors on decrypted HTTP traffic directly from within the Service Chain. In this article you will learn how to download, install, and configure the policy that enables the “SaaS Tenant Isolation” Service Extension. What is SaaS Tenant Isolation? SaaS Tenant Isolation is a function for managing tenant isolation (aka. restrictions) for several SaaS applications in a corporate environment. Tenant Isolation is a way for corporate entities to control access to non-corporate SaaS endpoints, typically to defend against misuse and sensitive data exfiltration. For example, an enterprise user may have Office365 accounts from multiple organizations. Tenant isolation prevents that user from copying data from their company’s Sharepoint to an Office365 endpoint in another organization. This service extension enhances the SSL Orchestrator built-in Office365 Tenant Restrictions service, providing for additional SaaS property controls: Office365 Tenant Restrictions v1 (for reference) Office365 Tenant Restrictions v2 (for reference) Webex (for reference) Google Gsuite (for reference1,reference2,reference3,reference4) Dropbox (for reference) YouTube (for reference) Slack (for reference) Zoom GitHub (for reference) ChatGPT (for reference) Note: the “for reference” links contain more information from each provider about how SaaS Tenant Isolation works Demo Video Deployment Prerequisites F5 BIG-IP version 17.1.x SSL Orchestrator version 11.1+ This article assumes you have SSL Orchestrator configured with a Topology and Service Chain. SaaS Tenant Isolation Service Extension Installation The information below is from the GitHub repository for the SaaS Tenant Isolation Service Extension (click here for a direct link). It includes an installer to create all the necessary objects. Download the installer: curl -sk https://raw.githubusercontent.com/f5devcentral/sslo-service-extensions/refs/heads/main/saas-tenant-isolation/saas-tenant-isolation-installer.sh -o saas-tenant-isolation-installer.sh CLI output: Make the script executable: chmod +x saas-tenant-isolation-installer.sh CLI output: Export the BIG-IP username and password: export BIGUSER='admin:password' Note: replace “password” with your actual BIG-IP admin password CLI output: Run the script to create all the SaaS Tenant Isolation objects: ./saas-tenant-isolation-installer.sh CLI output: The installer creates a new Inspection Service named "ssloS_F5_SaaS-Tenant-Isolation". Add this Inspection Service to any Service Chain that can receive decrypted HTTP traffic. Service Extension Services will only trigger on decrypted HTTP, so can be inserted into Service Chains that may also see TLS bypass traffic (not decrypted). SSL Orchestrator will simply bypass this Service for anything that is not decrypted HTTP. After following the steps above, the SSL Orchestrator screen should look like this: YouTube Tenant Restrictions To configure YouTube Tenant Restrictions, you will need to edit the iRule named “saas-tenant-rule” Navigate to Local Traffic > iRules > iRule List Click on the iRule named “saas-tenant-rule” (you may need to expand the iRule List) To enable the policy, set the value for “USE_YOUTUBE” from 0 to 1. Click Update. YouTube Tenant Restrictions can be set to either “Moderate” or “Strict”. Move the SaaS Tenant Isolation Service to a Service Chain Go to the SSL Orchestrator Configuration screen Click Service Chains then select your Service Chain Select the F5_SaaS_Tenant-Isolation Service and click the arrow to move it to the right Click Deploy Click OK Click OK The configuration is now complete Test YouTube Tenant Restrictions From a client computer, access youtube.com. An attempt to search for “adult content” results in the following: Microsoft (Office) 365 Tenant Restrictions The “saas-tenant-rule” has a set of editable configuration options for Office 365. For example: USE_OFFICE365_V1: Enables or disables tenant control for this SaaS endpoint. SAAS_OFFICE365_V1_HEADERS: Defines the header(s) to be be injected for this SaaS endpoint. Each line in the list consists of two values: Header Name: (ex. Restrict-Access-To-Tenants) Header Value: Typically and organization ID. The Ref: field in the comment block points to a resource that explains how this field must be populated. To customize the functionality navigate to Local Traffic > iRules > iRule List Click on the iRule named “saas-tenant-rule” (you may need to expand the iRule List) Office365 will be used in this example. The configuration is similar for all SaaS Tenants. To enable the policy, set the value for “USE_OFFICE365_V1” from 0 to 1. Click Update. Populate the header values required for your organization and click Update For reference, refer to: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tenant-restrictions For more details on Office 365 Tenant Restrictions, click HERE Testing Header Injection To test generic Header Injection from a client computer, access the following site: https://httpbin.org/headers By default you should see the following: Note the two x-headers injected at the bottom Then go back to the iRule “saas-tenant-rule” and scroll down to the “USE_TESTING” section These are the same headers you saw from httpbin.org The values can be customized like the following: Don’t forget to click Update Try the httpbin.org/headers site again and you should see the following: The two "X-Test-Header-" headers are injected by the iRule Conclusion F5 BIG-IP SSL Orchestrator is a great solution for managing SaaS Tenant Isolation. It gives you granular control over access to external SaaS applications. Microsoft Office365, Webex, Dropbox, GitHub, and many other SaaS applications are supported. Related Content Service Extensions with SSL Orchestrator User Coaching of AI Related Content SSL Orchestrator Service Extensions: DoH Guardian Office 365 Tenant Restrictions SSL Orchestrator Advanced Use Cases: Fun with SaaS Tenant Isolation Introduction to BIG-IP SSL Orchestrator Integrating Security Solutions with F5 BIG-IP SSL Orchestrator
