search cancel

FQDN name of authenticated user not showing up consistently in Cloud SWG access logs

book

Article ID: 257137

calendar_today

Updated On:

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

WSS Agent used to access internet via Cloud SWG services.

SAML authentication enabled for WSS Agent users, where SAML IDP server is Azure IDP.

Users access sites without issues but running reports against certain users does not show any expected matches i.e. running report of hits against certain domains, we seem to be missing users that are accessing that domain.

https://pod.threatpulse.com is reported as protected for the users whose names are missing from the access logs.

Environment

WSS Agent 8.2.2.

Azure SAML Identity Server.

Cause

Bypassing authentication for threatpulse.com domain.

Resolution

Remove the authentication bypass for the thretpulse.com domain.

Additional Information

When the WSS Agent starts the SAML authentication process after the tunnel has come up, the WSS Agent Webview plugin always issues a GET request for pod.threatpulse.com and expects a 307 redirect to saml.threatpulse.net in response. 

In our case, this GET request (where user agent is the browser and not the WSS Agent itself, which is used for healthchecks) is sent but with authentication bypassed for this domain, we simply forward it to the back end server and get the 200 OK response. We never complete the SAML authentication.

 

When SAML Authentication succeeds from the WSS Agent, we expect to see the following:

- GET request to http://pod.threatpulse.com gets a 307 redirect to https://saml.threatpulse.net:8443

- subsequent GET request to https://saml.threatpulse.net:8443 triggers a 302 redirect from Cloud SWG service to SAML IDP server (Okta in example below)

- subsequent SAML AuthnRequest is sent to Okta IDP server where user authenticates and corresponding assertion is sent back to WSS.

Attachments