WSS Agent users seeing authentication popup messages triggered by 401 Auth Challenge
Article ID: 270808
Updated On:
Products
Issue/Introduction
Users accessing internet via Cloud SWG service using WSS Agent.
Initial deployment worked well, and no problems seen either authenticating via SAML, or accessing Web sites.
As more users were added to the service, some users reported seeing an increase in seeing popup prompts asking for username and password. e.g. accessing teams.microsoft.com
The issue always occurs AFTER the Agent loads and BEFORE the SAML authentication is complete, appearing to happen on apps that were already loaded before agent and are aggressively trying to connect e.g. MS teams.We could see this too after the users session expired and application generated a new request before user re-authenticated.
We can replicate the symptoms by doing the following:
- In a browser go to https://notify.threatpulse.net/logout and make sure that the logout success message appears
- Open a new tab in same browser and go to any web site e.g. https://bbc.co.uk
- Verify that a popup appears requesting the user credentials - HAR file output will report a 401 response.
- Confirm that the HTTP logs show the request with the verdict of "authorization failed" and status of 401.
Why do users see popup messages when SAML authentication uses HTTP redirects? 401 status are returned by Web sites, when the proxy equivalent is a 407 status, yet we see 401 with Cloud proxy ...
Environment
WSS Agent.
SAML authentication.
Cloud SWG managed by UPE/Management Center.
Cause
A custom policy rule existed that forced an exception with a 401 status.
Customer has a PAC file sending traffic into 199.19.250.205 - issue would not be seen had no PAC file existed.
Resolution
removed the following policy that sent the authorization failed exception (with status 401!) when user was not successfully authenticated and hence not a member of specific groups the policy checked for in 'user_Access condition' below:
condition=!"User_Access" force_exception(authorization_failed) reference_id("NOT in CORRECT Group")
Another option is to not use a PAC file; when using PAC files, traffic destined for 199.19.250.205 is explicitly allowed by the WSS Agent regardless of whether user is authenticated or not.
Additional Information
When experiencing the issue, the popup was confirmed as being triggered by Cloud SWG proxy with the SAML_Realm as shown below.
When WSS Agent user is redirected to SAML IDP server, it is via a series of 30x status responses and the verdict is 'authentication_redirect_to_virtual_host' and not 'authorization_failed'. Here's a working example
2023-07-19 10:32:15 "DP2-GGBLO99_proxysg3" 3 x.x.x.x - - - - authentication_redirect_to_virtual_host DENIED "Technology/Internet" - 302 TCP_AUTH_REDIRECT GET - http example.com 80 / - - "curl/7.75.0" 192.168.2.86 16025 123 - - - - - - - - 0 "client" client_connector "-" "-" x.x.x.x "United States" - - - - - none - - - - none - - ICAP_NOT_SCANNED - - ICAP_NOT_SCANNED - - - HTTP/1.1 - - 0 - "United States" - "Ireland" 5 - - - - - - - - - - - - - - - - x:x:x:x:x:x:x:x ########-#######-####### - - "Invalid" "Invalid" - - -
Tracking the response within the Cloud SWG HTTP logs, we clearly see a verdict of authorization_failed with no status.
Since Cloud SWG never sends a 401 back by default with SAML based authentication, the following policy snippet showed where the authorization_failed status triggered the 401 ..
> (exception.authorization_failed
> (contact)
> (details "Your request was not authorized.")
> (format)
> (help)
> (summary "Access Denied")
> (http
> (code "401")
> (contact)
> (details)
> (format)
> (help)
> (summary)
> )
Feedback
