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.
Cloudsoc Gatelet deployment with Proxy Chaining
Cloudsoc by default requires the requests made to be authenticated and tagged by a valid Cloudsoc user id.
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:
; “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).