MacOS "NSURLErrorDomain error code -999" error on WSS Agent SAML login popup screen after user session expires on IDP server

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

WSS Agent setup and working well on MacOS

Users authenticate to WSS via SAML protocol where the session lifetime on WSS is 12 hours; their IDP session lifetime is also 12 hours

If a user keeps the machine unlocked and comes in after more than 12 hours of inactivity, the WSS agent popup screen displays the login page with NSURLErrorDomain error code -999 as shown below:

Clicking reload would cause the page to load correctly.

Environment

Version Monterey 12.2.1

WSSA version 8.0.60

3rd Party IDP server running on premise, but externally available too

 

 

Cause

IDP server having issues handling requests with stale cookies

Resolution

Switch the SAML AuthnRequests from using the Redirect binding to using the POST binding on WSS side

Additional Information

Agent communication to WSS via pod.threatpulse.com:80 endpoint returned the expected redirect to saml.threatpulse.net:8443 when session expired on WSS side. saml.threatpulse.net generated a SAML AuthnRequest and sent it to the IDP server, so we know that the communication to the IDP server was successful. 

After that, the client made a large number of requests to the IDP server at the same time (when successful we typically had one or two sessions!)

Knowing that the issue was with the IDP server In terms of troubleshooting, we enabled the ability to inspect the network traffic from within the popup generate a HAR file with the SAML popup using the following commands

sudo "/Applications/Symantec WSS Agent.app/Contents/MacOS/wssad" -p signalAction=enableWebViewDevTools
sudo killall -SIGUSR2 com.symantec.wssa.wssax

When done, we saw the HAR file and could see constant redirects from the IDP server to itself when the problem occured. The session information that was passed with the requests were invalid most likely as cookies were being expired. By clicking 'reload' on page, all cookies are reset as it simulates a request to the IDP server for the first time.

We POSTed the SAML authentication request instead of using the redirect, and this sorted the issue out from IDP side. We didn't get detailed logs from IDP server to understand why.