Calling Cloudsoc API's from a network fronted by a Web Proxy
Article ID: 269347
Updated On:
Products
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
The second option is to configure the web proxy to leave the authorization information upstream, and this can be done either for a specific traffic or to all the traffic.
1) Allow the authorization information of a specific traffic to be be forwarded upstream through the proxy:
Here is CPL code you can use if you want to forward authentication credentials explicitly to some web sites
<Proxy>
condition=forward_credentials authenticate.forward_credentials(yes)
define condition forward_credentials
url.domain=api-vip.elastica.net
end
In case you want to limit to specific user groups from Active directory
<Proxy>
condition=__GROUP137 condition=forward_credentials authenticate.forward_credentials(yes)
define condition forward_credentials
url.domain=api-vip.elastica.net
end
define condition __GROUP137
realm=Realm_name group=<Group_name>
end
2) Allow the authorization information to be forwarded for all the traffic through the proxy:
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
Feedback
