Access to Google site failed due to client's authorization header

book

Article ID: 168606

calendar_today

Updated On:

Products

ProxySG Software - SGOS

Issue/Introduction

The request to one of the Google sites has an authorization header before being challenged by the proxy's authentication policy. The request header looks like the one below:

POST https://accounts.google.com/OAuthLogin HTTP/1.1
Host: accounts.google.com
Connection: keep-alive
Content-Length: 35
> Authorization: Bearer ya29.IQB2fJ5dROAGhB8AAADUTd9BtBgvX9XGzWHNj1sK77wOKVnSGaskJfFRKYESuA
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: <snipped>

 

Cause

The HTTP proxy sees that the user has been authenticated, but isn't sure whether the credentials should be forwarded—it doesn't know whether the ProxySG consumed them on this transaction or perhaps on an earlier transaction. It then chooses not to forward them to avoid leaking them to a third-party origin content server.

 

Resolution

If the server were using basic credentials, you could forward them using the server.authenticate.basic gesture. However, that's not an option in this case since the client is presenting "Bearer" credentials.

The CPL policy "authenticate(no, upstream_authentication)" could be used in this case in order for the proxy to forward the client's credentials.