Cannot send SAML IDP server traffic into Cloud SWG with WSS / SEP Agent
Article ID: 274035
Updated On:
Products
Issue/Introduction
SAML authentication enabled for SEP Cloud and Web Access tunnel mode users (also applied to WSS Agent users).
SAML trust relationship has been successfully setup between Cloud SWG and Azure AD.
SAML IDP server endpoint automatically added to the Cloud SWG bypass list, but we need Azure traffic to go through.
Manually removing the SAML IDP server endpoint domain/IP from the bypass list on the Cloud SWG still sends traffic directly to the SAML IDP server.
Corporate traffic destined for Azure is expected to come from certain egress IP addresses and with this WSS Agent implementation we lose the ability to enable this as roaming users will come in from different IP addresses than the Cloud SWG egress IP address range; The ability to add Azure tenant ID info is lost.
Is it possible to send all Azure traffic into Cloud SWG at all times with WSS / SEP agents?
Environment
WSS Agent.
SEP Cloud and Web Access tunnel mode.
Cause
WSS / SEP Agents always bypass the requests to the SAML IDP server endpoints at authentication time by default.
Resolution
The following steps need to be performed to address issue:
1. To force traffic into the WSS Agent tunnel and overwrite any bypasses, the closed network always tunnel APIs can be used. By adding the SAML IDP server domain or IP address to either the /tunnel/ips or /tunnel/domain API endpoints, the WSS Agent will send any requests for this destination into the tunnel and not bypass Cloud SWG.
An example API request to force login.microsoftonline.com into the WSS Agent tunnel is shown below, where the Authorization: Basic header value should be modified from XXXXXXX to include the API username/password created for your tenant.
curl 'https://portal.threatpulse.com/api/rest/tunnel/domains' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic XXXXXXXXXXX' \
--data '["login.microsoftonline.com"]'
You can include the parent domain too, instead of the host, if the login page objects are being pulled from other hosts within that domain. Note that any CNAME domains within DNS responses for the SAML IDP server endpoint domain will also need to be added to the tunneled domain using APIs.
2. An Authentication bypass policy must also be added for this SAML IDP server endpoint domain (login.microsoftonline.com), to avoid getting into authentication loops.
3. the Cloud SAML IDP server endpoint domain must be removed from the SWG Portal domain bypass list. When the SAML configuration is initially added via the Cloud SWG Portal, the 'Endpoint URL' domain is automatically added to the domain bypass list, with the description 'Bypass SAML Endpoint'. Note too that any subsequent changes to the SAML configuration (e.g. group attribute change, signing certificate update) will cause the bypass entry to be re-added.
NOTE: If it is acceptable to bypass the SAML IDP server domain or IP address, then this closed network API is not required. In this case the host/client admins must make sure local firewalls allow traffic to the SAML IDP server endpoints when using WSS or SEP Agents. Without this, the initial WSS / SEP Agent SAML authentication will fail.
Additional Information
Since 2021, any SAML configuration changes on the Cloud SWG Portal automatically adds a domain bypass for the 'endpoint URL' domain defined, which causes all communication to the SAML SSO URL to be bypassed from Cloud SWG. It is possible to manually delete this bypass entry.
When the WSS / SEP Agent tries to authenticate the user, this is done through the Webview2 process (check out 'SAML Transaction Details for the WSS Agent access method' section for more details).
Since the WSS Agent bypasses the Webview2 process, all requests destined for the SAML IDP server will always be bypassed at auth time, even when the SAML IDP server domain is removed from the bypass list. Here's a snippet of debug logs that any traffic generated from this PID bypasses WSS including our IDP server traffic, where 15.197.141.255 is the IP address of an Okta IDP server used for testing.
wss wss-connection-manager.cpp 501 SendPacket 000014E4 00001708 0 09/22/2023-08:30:03.4877966 Info Sending packet 192.168.178.117:49819 as user (assigned): unauthenticated from user: Administrator from process: C:\Program Files (x86)\Microsoft\EdgeWebView\Application\117.0.2045.31\msedgewebview2.exe
krn app-driver.cpp 4864 CloudStreamOutboundClassify 00002458 00003010 5 09/22/2023-08:30:03.4880014 Debug PID connection passthru to 15.197.141.255:443
krn router.cpp 135 ActionOnPacket 00002458 00003010 5 09/22/2023-08:30:03.4880193 Debug Pid bypass from 192.168.178.117:49821
krn app-driver.cpp 3768 EvalTCPPacket 00002458 00003010 5 09/22/2023-08:30:03.4880197 Debug OutboundIPPacketClassify: passing through TCP packet for 15.197.141.255
The closed network always tunnel APIs can prioritise traffic sent into Cloud SWG and allows the authentication to complete successfully.
Feedback
