Description of authentication redirect verdicts

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Where I can find a description of following verdicts reported in Cloud SWG HTTP logs: 

• authentication_redirect_off_box
• authentication_redirect_to_virtual_host
• authentication_redirect_from_virtual_host
• authentication_success

Cloud SWG setup to authenticate users with SAML, and they appear to be logged during the process, but I cannot find any documentation on them.

I found references to common proxy verdicts but there are no references to these authentication specific cases.

Environment

Cloud SWG.

SAML Authentication or captive portal based authentication.

Resolution

These verdicts are all related to authentication (SAML or Captive Portal typically where redirects happen). 

Here is an example of what you will see with SAML based authentication with the various verdicts (exception-ids in HTTP logs) referenced at various stages of the authentication process.

- User-agent accesses a test URL http://example.com via Cloud SWG using an explicit access method
- Since the proxy has no session info about the user, it triggers a 307 redirect to the saml.threatpulse.net SAML SP virtual host with verdict "authentication_redirect_to_virtual_host"
- Since Proxy does not know who the user is at this stage, both user and group information is blank

2024-03-01 15:19:40 "DP2-GGBLO99_proxysg2" 566 #.#.#.# - - - - authentication_redirect_to_virtual_host DENIED "Technology/Internet" - 307 TCP_AUTH_REDIRECT GET - http example.com 80 / - - "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0" 192.168.2.85 16087 363 - - - - - - - - 465290 "Location" explicit_proxy "-" "-" #.#.#.# "United States" - - - - - none - - - - none - - ICAP_NOT_SCANNED - - ICAP_NOT_SCANNED - - - HTTP/1.1 - - 0 - - - "Ireland" 6 - - - - - - - - - - - - - - - - - 562cf190a5a345c5-0000000000087a53-0000000063ff6d0c - - "Invalid" "Invalid" - - -

- Subsequent request from user-agent will be to the SAML SP at saml.threatpulse.net domain on TCP port 80, and logged accordingly
- If a user session exists within the SAML SP session table, we will send user / group information back to the proxy with a verdict of uthentication_redirect_from_virtual_host
- In this example, it is the first request from this user and no prior session exists.

2024-03-01 15:19:40 "DP2-GGBLO99_proxysg2" 7 #.#.#.#  - - - - - PROXIED "Technology/Internet" - 200 TCP_ERR_MISS CONNECT - tcp saml.threatpulse.net 8443 / - - "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0" 192.168.2.85 39 227 - - - - - - - - 465290 "Location" explicit_proxy "-" "-" 199.19.250.205 "United States" - - - - - none - - - - none - - ICAP_NOT_SCANNED - - ICAP_NOT_SCANNED - - - HTTP/1.1 - saml.threatpulse.net 8443 - "United States" - "Ireland" 2 - - - - - - - - - - - - - - - - - 12345678912345-0000000000087a54-0000000063ff6d0c - - "Invalid" "Invalid" - - -

- With SAML based authentication, we need to redirect the user to the SAML IDP server which is on a remote host.
- HTTP logs will report a 302 redirect by default with the SAML AuthnRequest with a verdict of "authentication_redirect_off_box". It is off_box as the SAML authentication provider is always remote.

2024-03-01 15:19:40 "DP2-GGBLO99_proxysg2" 104 #.#.#.#  - - - - authentication_redirect_off_box DENIED "Technology/Internet" - 302 TCP_AUTH_REDIRECT GET - http example.com 80 / - - "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0" 192.168.2.85 16428 622 - - - - - - - - 465290 "NeilHome" explicit_proxy "-" "-" #.#.#.#  "United States" - - - - - none - - - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 128 - ICAP_NOT_SCANNED - - ICAP_NOT_SCANNED - - - HTTP/2 - saml.threatpulse.net 8443 - - - "Ireland" 6 - - - - - - - - - - - - - - - - - 987654321234-0000000000087a55-0000000063ff6d0c - - "Invalid" "Invalid" - - -

- The SAML IDP server traffic may be bypassed from Cloud SWG but if it is not, we need to make sure that we have an authentication bypass for this domain.
- For this example, the IDP server is an masked (exampleIDP.com) Cloud instance and here's a snippet of a log entry showing request to this IDP server, which is bypassed from Auth on Cloud SWG

2024-03-01 15:19:40 "DP2-GGBLO99_proxysg2" 68 #.#.#.#  - - - - - OBSERVED "Technology/Internet" - 200 TCP_ACCELERATED CONNECT - tcp exampleIDP.com 443 / - - "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0" 192.168.2.85 39 237 - - - - - - - - 465290 "Location" explicit_proxy "-" "-" 15.197.141.255 "United States" - - - - - none - - - - none - - ICAP_NOT_SCANNED - - ICAP_NOT_SCANNED - - - HTTP/1.1 - exampleIDP.com 443 - - - "Ireland" 2 - - - - - - - - - - - - - - - - - 1111111111111111-0000000000087a56-0000000063ff6d0c - - "Invalid" "Invalid" ##################### "exampleIDP.com" -

- Assuming the user authenticates successfully at the remote Okta IDP server, an assertion will be generated in behalf of the user and sent back to the Cloud SWG saml.threatpulse.net service
- Once the proxy gets the assertion back from the Okta IDP server and validates it, we should see a 'authentication_redirect_from_virtual_host' verdict but this time see the user / group info for the first time.
- We see the 302 redirect sending the user back to the original URL he was going to

2024-03-01 15:19:46 "DP2-GGBLO99_proxysg2" 17 #.#.#.# "[e-mail]" "############" examplegroup- authentication_redirect_from_virtual_host DENIED "Technology/Internet" https://exampleIDP.com/ 302 TCP_AUTH_REDIRECT POST - http example.com 80 / - - "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0" 192.168.2.85 16557 11230 - - - - - - - - 465290 "Location" explicit_proxy "-" "-" 34.160.111.145 "United States" - - - - - none - - - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 128 - ICAP_NOT_SCANNED - - ICAP_NOT_SCANNED - - - HTTP/2 - saml.threatpulse.net 8443 - "United States" - "Ireland" 6 - - - - - - - - - - - - - - - - - 222222222222222-0000000000087a6a-0000000063ff6d12 - - "Invalid" "Invalid" - - -

// Finally get an authentication_success verdict confirming that all worked and can access the original URL that user intended to access
// Proxy now sees that the user is valid, adds it to it's auth table and redirects back to original URL

 2024-03-01 15:19:46 "DP2-GGBLO99_proxysg2" 2 #.#.#.# "[e-mail]" "############" examplegroup - authentication_success DENIED "Technology/Internet" - 307 TCP_DENIED GET - http example.com 80 / - - "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0" 192.168.2.85 16335 453 - - - - - - - - 465290 "Location" explicit_proxy "-" "-" 34.160.111.145 "United States" - - - - - none - - - - none - - ICAP_NOT_SCANNED - - ICAP_NOT_SCANNED - - - HTTP/1.1 - - 0 - - - "Ireland" 6 - - - - - - - - - - - - - - - - - 3333333333333-0000000000087a6c-0000000063ff6d12 - - "Invalid" "Invalid" - - -

2024-03-01 15:19:46 "DP2-GGBLO99_proxysg2" 122 #.#.#.#  "[e-mail]" "##################" examplegroup- - OBSERVED "Technology/Internet" - 302 TCP_NC_MISS GET text/html;%20charset=utf-8 http example.com 80 / - - "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0" 192.168.2.85 483 554 - cas_group - "{ %22expect_sandbox%22: false }" no - - - 465290 "Location" explicit_proxy "-" "-" #.#.#.#  "Ambiguous - Special Use" - - - - - none - - - - none - - ICAP_NOT_SCANNED - - ICAP_NO_MODIFICATION - - - HTTP/1.1 HTTP/1.1 - 0 #.#.#.#  - - "Ireland" 6 - - - - - - - - - - - - - - - - - 44444444444444-0000000000087a6e-0000000063ff6d12 - - "Invalid" "Invalid" - - -