Securing Public Applications with SonicWall Cloud Secure Edge (CSE)
Add device trust and Zero Trust policy enforcement to your SaaS applications with CSE's access-focused Cloud Access Security Broker (CASB)
- Updated on
- 5 minutes to read
-
Contributors
Overview
Public applications, also known as Software-as-a-Service (SaaS) applications, are cloud-based software hosted and delivered by software vendors. Because these applications are public resources hosted on your vendor’s servers and accessed over the internet (unlike private resources which are hosted on your servers in your private networks) they often bypass key enterprise security controls.
Most organizations enable Single Sign On (SSO) and Multi-factor Authentication (MFA) for strong user authentication to public applications, but are unable to enforce zero-trust security controls such as device trust requirements for device posture validation, continuous authorization to revoke user access mid-session, etc.
Enforcing zero-trust security for SaaS applications is particularly challenging because of the variety of applications an organization uses and the different levels of risk they pose. Furthermore, a one-size-fits-all approach to zero-trust security seldom works because SaaS applications are central to myriad critical workflows, such as access from native apps, access from employee-owned mobile devices, third-party access from unmanaged devices, cloud-based integrations with other products, etc.
CSE secures public applications with an access-focused Cloud Access Security Broker (CASB): on top of your existing SSO and MFA, it adds device trust and Zero Trust policy enforcement to how users reach your SaaS applications. It does this with two independent techniques — IdP Federation and IP Allowlisting — both of which leverage CSE’s trust scoring and access policy frameworks.
What CSE’s CASB covers today: access control — device trust and Zero Trust policy enforced at sign-in or at network egress. Proxy-based controls are possible but not recommended, and API-based CASB (in-app activity visibility / DLP) is on the roadmap. See the FAQs.
The two techniques are alternatives or complements — not a sequence and not dependent on each other. You can use either on its own, or both together (many organizations do). Each identity-provider guide (Entra ID, OneLogin, Okta) documents both options side by side, which is why you see a federation doc and an IP allowlisting doc under each provider.
| Technique | How it enforces Zero Trust | Scope | Choose it when |
|---|---|---|---|
| IdP Federation (a.k.a. IdP-routed) |
Routes authentication through CSE so device trust is validated at sign-in, before your IdP issues the SSO token | All applications behind your IdP | You want the strongest control — device posture checked on every login |
| IP Allowlisting | Requires traffic to egress through CSE (Service Tunnel / Access Tier IPs); the app or IdP only permits known CSE IP addresses | Per application; also works for apps not integrated with your IdP | You want a lighter, per-app control, or the app is not federated |
Doc status: CSE-side steps reviewed 2026-06-29. The third-party IdP console steps follow the vendor’s own documentation and should be confirmed against the live admin console, which can change without notice.
Use Cases
You may use just one or both techniques to secure public applications used by your organization. Some common scenarios for each technique are listed below, along with the request flow diagram that describes how the zero-trust security mechanism works.
IP Allowlisted SaaS Applications
You can define a Service Tunnel in CSE and configure IP allowlisting when you need to enable:
- Restricted access to public applications that are not integrated with your IDP
- Device trust for a specific SaaS application(s) without changing authentication settings in IDP or the application
- A migration of IP allowlisting from the corporate VPN to a modern VPNaaS
Federated SaaS Applications — IdP Federation
You can define a Federated SaaS App in CSE and configure authentication federation when you need to enable:
- Device trust checks without running a VPN client or intercept network traffic on the device
- Device trust checks and certificate authentication before users can establish a single sign-on session with your IDP
- Device trust checks and certificate authentication before users can access SaaS applications integrated with your IDP
- SAML/OIDC authentication and device trust policy enforcement for custom SaaS applications
FAQs
Do you provide a Proxy-based CASB?
Yes! You can use CSE for proxy-based controls to SaaS applications. The configuration steps are similar to the IP Allowlisting steps described above. Instead of defining a Service Tunnel for your SaaS application, you can define a Hosted Website.
Applying proxy-based controls to SaaS applications is often fragile - APIs change constantly, native apps use certificate-pinning that breaks proxies, etc - so CSE doesn’t typically recommend a proxy-based approach for zero-trust access to SaaS applications.
Do you provide an API-based CASB?
Providing API-based controls for SaaS applications in on our roadmap. Please contact your account team for details on our approach and timelines.
What’s next
Read about how to configure IdP Federation and IP Allowlisting in CSE. The IdP Federation guides walk you through routing authentication through CSE so device trust is validated at sign-in, while the IP Allowlisting guides walk you through forcing application traffic to egress through CSE so only known CSE IP addresses are permitted.