Debugging Authentication in Web Isolation

Products

• Web Isolation

Issue/Introduction

Troubleshooting Authentication in Web Isolation

Resolution

To debug, first, it should be verified that the correct authentication is being implemented.

The authentication mode you select depends primarily on your topology. Use the use cases listed in the table below as a guide to assist you with selecting the appropriate authentication mode.

Note
Internal identity authentication and Active Directory authentication can be used in Proxy mode as well as in Server mode; however, SAML must be used in Server mode.

Use Case	Authentication Mode
Symantec Threat Isolation explicit proxy	Proxy
A downstream proxy between the endpoint browser and the Threat Isolation Gateway authenticates the endpoints using the HTTP response: 407 Proxy Authentication Required. In this case, the Gateway must be configured with Server authentication mode. Otherwise, the Gateway can be configured with Proxy authentication mode.	Server
Your company uses Web Application Isolation Gateways. NOTE: Web Application Isolation Gateways use Server authentication regardless of the mode with which they are configured.	Server
SAML Authentication	Server

Note
It is recommended to use Symantec Secure Web Gateway (ProxySG) as your downstream proxy. As products from the same vendor, Symantec Threat Isolation and Symantec ProxySG can be integrated smoothly. This convenience is not available when using any other product.

If your organization’s endpoints communicate indirectly with the Threat Isolation Proxy through a downstream proxy, the proxy forwarding policy in your downstream proxy must support rule-based definition.

In this topology, endpoint communication with the Threat Isolation Proxy and the TIE is carried by the downstream proxy responsible for the forwarding.

The downstream proxy forwards traffic to one or more selected Threat Isolation Gateway clusters using proxy chaining.

As shown in the figure above, the Symantec Threat Isolation Platform distinguishes between two types of third-party proxies, according to their location in relation to the Gateway: the downstream proxy resides between the endpoint and the Threat Isolation Proxy, while the next hop proxy/server resides between the Gateway and the Internet.

For simplicity, the figure contains just one next hop proxy/server. Real-life topologies can contain multiple next hop proxies/servers, with the Threat Isolation Proxy and the Threat Isolation Engine (TIE) pointing to different next hop proxy/server machines.

Note that a downstream proxy can act as both downstream proxy and next hop proxy/server on the same machine, as illustrated in the figure below. In this case, the policy will be run twice: once before the request is forwarded to the Symantec Threat Isolation Platform, and again before it is forwarded to the Internet.

Since the downstream proxy resides between the endpoints and the Threat Isolation Gateway, it must preserve the original data of the source IP and the authenticated user. This data is contained in the following standard request headers:

• X-Forwarded-For (XFF) header – Contains the originating IP address for which the request was forwarded. The downstream proxy adds the XFF header to the request before forwarding it to the Threat Isolation Proxy.
• X-Authenticated-User (XAU) header – Signifies that the downstream proxy as authenticated the end user who originated the request. The downstream proxy adds the XAU header to the request before forwarding it to the Threat Isolation Proxy.
• X-Authenticated-Group (XAG) header – Signifies that the downstream proxy has authenticated the group that originated the request. The downstream proxy adds the XAG header to the request before forwarding it to the Threat Isolation Proxy.

Proxy Authentication Mode

In Proxy authentication mode, the Gateway issues a Proxy challenge (HTTP 407) for every new connection.  

Note
When a downstream proxy between the browser and the Gateway authenticates the endpoints using the HTTP response: 407 Proxy Authentication Required, the Server authentication mode must be used. For more information, see the section "Server Authentication Mode" below.

The following flow chart illustrates the initial browsing flow in Proxy authentication mode. Each leg is explained below.

From the above figure, see further explanation of each leg above. Understanding these will help debug the authentication challenge.

1. The client (browser) surfs to a website on the Internet.
2. Since the Threat Isolation Proxy does not know the user’s identity, it returns a standard HTTP response: 407 Proxy Authentication Required (for an explanation, see https://www.iana.org/assignments/http-status-codes/httpstatus-codes.xhtml).
3. The browser gets the identity information from the user or from the OS, then sends the authentication information to the Threat Isolation Proxy.
4. The Threat Isolation Proxy verifies with the identity provider that the user is authenticated. It then returns the 200 OK status that concludes authentication, together with the HTML content. The HTML content depends on the matched rule. 

Note: Authentication is required only when the matched rule demands it. For more information, see section "Match Criteria Flow".

Match Criteria Flow

The match criteria of a security rule are evaluated in the following order: Source (first), Destination (second), Request Headers (third), User (fourth).

• If there is a match on all four criteria, Symantec Threat Isolation determines the verdict enacted for the request.
• If there is no match for Source (first), Symantec Threat Isolation does not even check the other three match criteria (Destination, Request Headers, and User). Instead, Symantec Threat Isolation continues to the next rule in the security policy's list.
• If there is a match for Source, Symantec Threat Isolation checks Destination. If there is no match for Destination, Symantec Threat Isolation continues to the next rule. And so it continues for the remaining criteria.
• Authentication is an expensive action that can slow down the browsing experience. Therefore, users are authenticated only if the User criteria specifically require authentication. For more information, see section "Defining Policy Rules", the User field, and section "Unauthenticated Users in Activity Logs".

Skipping Authentication when Egress IP Has Been Authenticated

Some applications do not support Proxy authentication. To avoid connectivity issues in such cases, Symantec Threat Isolation allows authentication to be skipped when the source egress IP address (the source IP address that the traffic comes from) has already been authenticated within the configured authentication caching timeout. The policy can be edited to include criteria for skipping authentication.

When these criteria are matched and the source egress IP address was authenticated previously, the user is considered trusted and authentication will be skipped. The activity log displays “Generic User” instead of the user name when user authentication was skipped for unauthenticated requests. In that case, rules with a specific Access Role were skipped during matching.

Server Authentication Mode

In Server authentication mode, the Threat Isolation Gateway issues an Authentication challenge (HTTP 401) for every new connection.

The following flow chart illustrates the initial browsing flow in Server authentication mode. Each leg is explained below.

1. The client (browser) surfs to a website on the Internet.
2. The Threat Isolation Proxy configured with the Server authentication mode returns a 302 Redirect to Service Provider (SP) rather than the standard 407 response. (The Service Provider (SP) is the Threat Isolation Proxy.)
3. The browser browses to the Service Provider (SP).
4. Since the Service Provider (SP) does not know the user’s identity, it returns 401 Authentication required.   
5. The browser gets the identity information from the user or from the OS, then sends the authentication information to Threat Isolation Proxy.
6. The Service Provider (SP) returns a 302 Redirect to the original URL, with a Symantec Threat Isolation query-param that contains a token. It also sets a cookie for persistency. This cookie makes steps 4 and 5 redundant in future requests.
7. The browser asks for the URL provided in step 6, and attaches the token.
8. The Threat Isolation Proxy redirects the browser to the original URL of the requested website. It also sets a cookie for persistency. This cookie makes steps 1-8 redundant in future requests.
9. The browser asks for the original URL of the requested website with a cookie.
10. The Threat Isolation Proxy verifies with the identity provider that the user is authenticated. It then returns the 200 OK status that concludes authentication, together with the HTML content. The HTML content depends on the matched rule.

Skipping Authentication when Egress IP Has Been Authenticated

When a proxy resides in the cloud, it cannot communicate directly with an authentication server that resides in the LAN. If redirect cannot be done in this case, authentication is likely to fail, resulting in connectivity issues for Bypass and
Inspect actions. (This is not relevant for isolated web traffic.) Connectivity issues can also be experienced by websites that apply Content-Security-Policy[1] such as Facebook.com.

To address the connectivity issues, Symantec Threat Isolation allows authentication to be skipped when the source egress IP address (the source IP address that the traffic comes from) has already been authenticated within the configured authentication caching timeout. The policy can be edited to include criteria for skipping authentication. When these criteria are matched and the source egress IP address was authenticated previously, the user is considered trusted and authentication will be skipped. The activity log displays “Generic User” instead of the user name when user authentication was skipped for unauthenticated requests. In that case, rules with a specific Access Role were skipped during matching.

For more information, follow this Symantec support link, and refer to the Server Authentication Mode section:

https://knowledge.broadcom.com/external/article?legacyId=tech252383

 

Next, with the debugging process, the "Activity Logs" will have to be checked. 

Symantec Threat Isolation Platform authenticates a user's identity using an external Identity Provider. To help you troubleshoot issues involving traffic to the identity provider, the Authentication steps above can be reported in the Activity Logs.

1. Go to:

Policies > Update Policy > Authentication Settings > Server Mode > Settings.

2. Under Logging Settings, click More.

3. Select the authentication steps that you want logged.

4. Click Update. 

You may share the the Activity Logs on this case, if required.

Also, with the authentication profile set and the correct authentication mode implemented, if the customer is working with a software requiring authentication based on Windows, the following should be set, on the browser.

An additional debug log would be the HAR file, for the affected web request. Any authentication failure would also show up there.