Calling Cloudsoc API's from a network fronted by a Web Proxy
search cancel

Calling Cloudsoc API's from a network fronted by a Web Proxy

book

Article ID: 269347

calendar_today

Updated On:

Products

CASB Advanced Threat Protection CASB Audit CASB Gateway CASB Gateway Advanced CASB Security Advanced CASB Security Advanced IAAS CASB Security Premium CASB Security Premium IAAS CASB Security Standard CASB Securlet IAAS CASB Securlet SAAS CASB Securlet SAAS With DLP-CDS

Issue/Introduction

Cloudsoc API's uses the API token's to authenticate to Cloudsoc for both authentication and authorization purposes. 

Running the API calls behind a web proxy would need a special consideration, especially if the proxy enforces the authentication on the endpoint (Machines/users).

Environment

The web traffic of the network is controlled by a web proxy.

Cause

The token is sent to Cloudsoc on an HTTP header named "Authorization" which is considered as a confidential information by the proxy, as a security measure and in order to protect the corporate network for involuntary leaking of a confidential information, the proxy strips off the header as a default action. 

 

The expected behavior when facing this issue is to get "Unauthenticated" response when running the call behind a proxy, but it would work if the call is made with a direct connection without a proxy in the middle.

Resolution

To fix this, a change on the proxy is required in order to white list the API Server to allow the Authorization header to be sent upstream to Cloudsoc.

 

Taking Bluecoat ProxySG as an example, one way of doing this is by adding this CPL command to the Policy section:

<proxy>
url=api-vip.elastica.net authenticate(no, upstream_authentication)

This would tell the proxy to bypass the proxy authentication and at the same time to forward the Authorization header upstream to server "api-vip.elastica.net" which is the API Server of Cloudsoc for the US (for the other regions please use the appropriate host name for your region like https://api.eu.elastica.net).

 

The rule can be modified to be more specific, for example if the IP address of the machine (or IP range) that is supposed to run the Cloudsoc API calls is known and fixed, then it can be added to the condition like:

<proxy>
url=api-vip.elastica.net client.address=xxx.xxx.xxx.xxx authenticate(no, upstream_authentication)

 

Or the region could be added (if the geolocation feature is enabled and downloaded to the proxy), like:

<proxy>
url=api-vip.elastica.net client.address.country=(US, CA) authenticate(no, upstream_authentication)

 

 

Additional Information

There is a command line on the proxy that would change the default behavior of removing the sensitive information before forwarding the traffic upstream. if executed, it would allow the Authorization to be sent upstream but that would be a global permission to any website. which may introduce a security concern.

Typically that can be used in a proxy chaining deployment where the next hop is a controlled hop within the same environment.

For the internet bound proxies, the recommendation is to use the CPL code instead (first option list above) which limits the exception to a very specific case(s).

 

For reference the command line in the proxy is: 

(config)security force-credential-forwarding enable

 

Command line Reference from Proxy Knowledge base can be found here