With identity proxies, companies can implement the use case "secure SaaS access from BYOD devices". This means that instead of simply "bluntly blocking" access to SaaS applications using IdP functions such as Microsoft's Conditional Access if the user is coming from an unmanaged device, the session can be dynamically redirected to browser isolation or released for native access based on the device status.
This enables secure access to SaaS applications from private devices without compromising the user experience.
Traditionally, companies simply block access to SaaS applications (e.g. Salesforce) if the user is not accessing them from a managed device. To do this, rules are defined in Entra Conditional Access, for example, which check the compliance status of the device (e.g. "is domain joined"). Access is only permitted if the device is "compliant", i.e. "domain joined", otherwise it is blocked.
The user therefore logs in to the SaaS application. The SSO-configured SaaS recognizes that it needs to authenticate the user at the IdP and forwards the request to the IdP. The IdP then responds to the SaaS as to whether the user is allowed access or not. Accordingly, the login is allowed or denied (without going into the various SAML methods - SP-initiated or IdP-initiated - here).
This effectively means that the user is not granted access from their private device. However, it would be much nicer if the user could have access, but IT could control what they are allowed to do on company devices - and what they are not allowed to do on private devices.
When using an identity proxy (part of an SSE solution), access to a SaaS application is not simply blocked or allowed. Instead, a third option is created: browser isolation. Within this isolation, you can control in detail what the user may or may not do in the session.
Common features are
Effectively, this means that users can also access SaaS applications securely from private devices - without the risk of data loss, malware infection or breaches of compliance guidelines. Secure BYOD for SaaS in other words.
In order for BYOD devices to be dynamically redirected to a browser isolation, the authentication of the SaaS application must first run via the SSE component. This means that the SAML request does not go directly to the IdP, but first to the SSE provider.
The SSE provider checks whether the request originates from a managed or unmanaged device and remembers this information. The request is then forwarded to the actual IdP (e.g. Entra), where it is verified whether the user account is active, exists and is activated for the SaaS. Group memberships can be passed through so that IdP-based roles and authorizations in the SaaS continue to function.
If the user is authorized to use the SaaS, the SSE provider - based on the device status - either sends a redirect to the browser isolation or transparently authenticates the user to the SaaS.
Whether a device is considered "managed" is determined via a browser plugin or the existence of an SSE agent on the device. The above-mentioned security guidelines are then applied within the browser isolation.
Both Zscaler and Cloudflare can be used as identity proxies and support browser isolation (with slightly different features). The following example shows isolated (Zscaler) and native (Cloudflare) access.
Conclusion
Et voilà: We have enabled the secure use of SaaS applications on private devices!
Users can now finally access corporate SaaS from their personal devices - without compromising (data) security.
Would you have known?