ProxySG returns an HTTP 401 status code when using a "redirect-based" authentication mode

Products

• ProxySG Software - SGOS

Issue/Introduction

You may intermittently experience an authentication popup window when your ProxySG is configured to use one of the redirect-based authentication modes -

origin-cookie-redirect

origin-ip-redirect

form-cookie-redirect

form-ip-redirect

A packet capture shows the ProxySG returning an HTTP 401 status code, instead of the expected redirect code (307 or 302.)  

Resolution

This normally occurs if the client sends a POST/PUT request that needs to be authenticated.

 

By default, authentication modes which redirect the browser use an HTTP 307 response code for Internet Explorer and an HTTP 302 response code for all other browsers.  If an HTTP POST or PUT request requires authentication, a 307 redirect properly preserves the POST/PUT data, while a 302 redirect will convert the request to a GET and lose the POST/PUT data.  The default behavior is to always preserve the POST/PUT data even at the cost of the authentication mode.  To avoid losing the POST/PUT data, browsers which would use a 302 redirect are downgraded to a non-redirect authentication mode.

If the POST/PUT contains a multi-part mime type, Internet Explorer will not correctly preserve the data with a 307 redirect.  The default behavior is to downgrade all multi-part POST/PUT requests to a non-redirect authentication mode.  Downgrading the authentication mode preserves the data, but means that the user is not authenticated using the virtual URL.  This can be an issue if credentials need to be secured by using an SSL virtual URL. This property can be used to override the default behavior and force the use of 307 redirects.  This will ensure that the user is authenticated using the virtual URL.

 

There are two different popups which may occur:
Most modern browsers support 307 redirects, but browsers other than Internet Explorer obey the RFC and display a pop-up asking the user if they want to repost/resubmit the data.  This pop-up can be repeated numerous times during authentication.

 

Furthermore, when the proxy downgrades to a non-redirect authentication mode, it sends an HTTP 401 "Authentication required" response code. The web browser treats this as an authentication request from the actual web server, rather than the proxy. Since the web server is not in a trusted security zone, authentication credentials are not automatically submitted, and an authentication popup window appears.

 

The CPL code given below can be used to force 307 redirects for a given browser.  This would help avoid the issue where the proxy returns a 401 status code and causes an authentication popup window.

 

Please note:

Do not use this CPL code to force 307 redirects for Internet Explorer. Doing so will cause multi-part mime data in POST/PUT requests to be lost.

By using this CPL code, web browsers other than Internet Explorer may pop up a window asking for confirmation whether to resubmit the POST/PUT data. This is the behavior dictated by the RFC and cannot be worked around.

 

Example

 

This example enables 307 redirects for Firefox. All other browsers will see the default behavior.  Note that request.header.User-Agent condition is a regex and can be used to match any particular browser.  This CPL code can be added to the proxy's local policy file.  For information on how to add policy to the local policy file, please see 000010101.

<proxy>
request.header.User-Agent="Firefox" authenticate.force_307_redirect(yes)

 

The solution above only applies to Firefox. See KB3788 for the solution as it applies to versions of Internet Explorer that support this functionality.

 

Alternatively, you can bypass authentication and allow POST requests:

 

<proxy>

      http.method=POST authenticate(no) allow

 

**Warning*** In most cases disabling authentication for POST requests will not cause any problems but because of the fact that user/group authorization specific policy rules will NOT apply for POST requests when disabling authentication for such, there is a possibility that unexpected behavior may occur. For example: If there is a rule set in policy to forward only specific users/groups to a forwarding host such as another proxy or server, POST requests for such services will not be forwarded and this may disrupt service for those requests. In that case those destinations should be excluded from matching on this policy.

 

Example:

 

<proxy> condition=!"Authenticated_POSTs_Required"

     http.method=POST authenticate(no) allow

 

define condition Authenticated_POSTs_Required

     url.host=proxy.example.com

     url.host=server.example.com

end

 

; The policy above excludes the sites defined in the condition from matching on the rule in the layer (negated by "!" in the layer guard).