Making API calls to a sanctioned Application through Gatelet in a Web Proxy Chaining deployment
search cancel

Making API calls to a sanctioned Application through Gatelet in a Web Proxy Chaining deployment

book

Article ID: 378552

calendar_today

Updated On:

Products

CASB Gateway CASB Gateway Advanced CASB Security Advanced CASB Security Standard CASB Security Premium

Issue/Introduction

A fundamental requirement for any sanction application to be controlled by Cloudsoc Gatelet is to forward all the interesting traffic to CloudSWG (WSS) and at the same time for the traffic to be authenticated properly against a valid user.

In some use cases, direct API calls are required to be made directly to  to the SaaS application sanctioned by Cloudsoc Gatelet. In this case, the traffic would be routed correctly to Cloudsoc but the Authentication requirement would break it. This article goes through a few suggestions.

Environment

Cloudsoc Gatelet deployment with Proxy Chaining

Cause

Cloudsoc by default requires the requests made to be authenticated and tagged by a valid Cloudsoc user id.

Resolution

Here are two options:

 

1- Use a dummy account

In this case, you would create a dummy account (for example: [email protected] where example.com is the primary domain) with a NetBIOS name being (Domain\Automation) as an example too.

In this case, you would:

  1. Create a Cloudsoc user with the dummy account as above
  2. Define the API traffic either by the endpoint or by the source IP of the agent (Server IP, or URL of the API server ..etc)
  3. Generate the base64 static encode of the dummy user id ( for example in the example above Domain\Automation , the base64 encoding would be RG9tYWluXEF1dG9tYXRpb24 )
  4. Disable The proxy authentication on the API traffic (use the definition  step 2)
  5. On the on-prem proxy, Inject the BC_User header with the static value generated on step 2 (use a static value without the need to use a substitution variable), and limit the injection to the Automation traffic (by the source IP address of the server for example).

 

Example from Symantec ProxySG 

; “semi colon” for comments
; define API Traffic either by URL or IP
define condition API_Traffic
    ; Add any other public IPs that are not to route to WSS
    url.domain=api-endpoint.example.com         ; API Endpoint
    client.ip=10.20.30.40            ; Private IP of the API agent (internal)
end

 

; define API Traffic either by URL or IP

define action Auth_Cloud
    set( request.x_header.BC_Auth_User, "$RG9tYWluXEF1dG9tYXRpb24" )
    set( request.header.Client-IP, "$(client.address)" )
End


; The bypass list definition for use in <Forward> layers
;
<proxy>

condition=API_Traffic authenticate(no) action.Auth_Cloud(yes)

 

2- Enabling the guest user access

A less recommended approach is to enable the guest user access. This is a tenant wide configuration and it can be limited to a specific domain. if it is enabled, it would allow any unauthenticated traffic through Cloudsoc and at the same time it would mark it as "Guest" traffic whether it is intended or not (Here is a KB article for more details).

 

Additional Information