

Create a Custom Choreo Connect Policy

Choreo Connect supports the following operations and the policies supporting these operations are shipped with the WSO2 API Manager by default. The following table contains the action name and parameters of the operations that are supported in Choreo Connect.

Action Name	Parameters	Applicable Flows	Description
SET_HEADER	headerName headerValue	Request	Set a header in the request flow.
REMOVE_HEADER	headerName	Request	Remove a header in the request flow.
ADD_QUERY	queryParamName queryParamValue	Request	Add a query param in the request flow.
REWRITE_RESOURCE_METHOD	currentMethod updatedMethod	Request	Change the HTTP method of a resource in the request flow.
REWRITE_RESOURCE_PATH	resourcePath includeQueryParams	Request	Rewrite the resource path in the request flow.
CALL_INTERCEPTOR_SERVICE	interceptorServiceURL includes (this require a comma separated string, which describes what should be included in the request body of the interceptor service)	Request Response	Call an interceptor service in request or response flow. For more information, visit Message Mediation.
OPA	requestGenerator serverURL accessKey policy rule sendAccessToken additionalProperties maxOpenConnections maxPerRoute connectionTimeout	Request	Validate the request against the Open Policy Agent server.

Custom Choreo Connect policies can use these actions and the template or a specific value in parameters.

Note

Choreo Connect policy definitions are in the .gotmpl file extension. Its content type is YAML and is templated with go templates.

Sample 1 - Custom Call Interceptor Policy

Let's create a new policy using the action CALL_INTERCEPTOR_SERVICE. The following is the content of the default call interceptor policy definition that comes by default with the distribution. You can download the default call interceptor service policy from the Publisher Portal.

ccCallInterceptorService.gotmpl

definition:
 action: CALL_INTERCEPTOR_SERVICE
 parameters:
   interceptorServiceURL: {{ .interceptorServiceURL }}
   includes: {{ .includes }}

Say you have an interceptor service that converts XML payload to JSON with the server URL https://xml-to-json-interceptor:8443, let's create a policy named XML to JSON Call Interceptor. Learn more about Choreo Connect interceptors on Message Transformation. Since you only need the request and response payload, you can specify includes as request_body,response_body.

Let's create the policy definition xmlToJsonCallInterceptor.gotmpl with the following content.

xmlToJsonCallInterceptor.gotmpl

definition:
 action: CALL_INTERCEPTOR_SERVICE
 parameters:
   interceptorServiceURL: https://xml-to-json-interceptor:8443
   includes: request_body,response_body

You can create the policy specification for this policy as follows. Since there are no templated attributes in the policy definition, you can keep policyAttributes in the spec as an empty array.

Sample 2 - Custom OPA Policy

Let's create a new policy with the action OPA. The following is the content of the default OPA policy definition that comes by default with the destribution opaPolicy.gotmpl.

opaPolicy.gotmpl

definition:
  action: OPA
  parameters:
    requestGenerator: ""
    serverURL: {{ .serverUrl }}
    {{- if .accessKey }}
    accessKey: {{ .accessKey }}
    {{- end }}
    policy: {{ .policy }}
    rule: {{ .rule }}
    {{- if .sendAccessToken }}
    sendAccessToken: {{ .sendAccessToken }}
    {{- end }}
    {{- if .additionalProperties }}
    additionalProperties: {{ .additionalProperties }}
    {{- end }}
    {{- if .maxOpenConnections }}
    maxOpenConnections: {{ .maxOpenConnections }}
    {{- end }}
    {{- if .maxPerRoute }}
    maxPerRoute: {{ .maxPerRoute }}
    {{- end }}
    {{- if .connectionTimeout }}
    connectionTimeout: {{ .connectionTimeout }}
    {{- end }}

Note

You can create a custom request generator and define it in the parameter requestGenerator. For a detailed description on creating a custom request generator, visit Custom OPA Policy for Choreo Connect.

Let's say we want to validate requests with a OPA server that is used to validate a set of APIs centrally. Let's create a custom policy with name centralOpaPolicy.

Let's create the definition file. We can have default values added to the parameters of the action “OPA”.

centralOpaPolicy.gotmpl

definition:
  action: OPA
  parameters:
    requestGenerator: ""
    serverURL: https://central-opa:8181
    accessKey: ""
    policy: {{ .myPolicy }}
    rule: {{ .myRule }}
    sendAccessToken: true
    additionalProperties: ""
    maxOpenConnections: 10
    maxPerRoute: 5
    connectionTimeout: 30

You can now define the policy spec and since you have templated myPolicy and myRule, you should include those in the policy spec. The following is the sample spec for the above policy definition.

centralOpaPolicy.json

{
 "category": "Security",
 "name": "opaPolicy",
 "displayName": "Validate Request With OPA Policy",
 "description": "With this policy, user can validate requests based on the OPA policy engine",
 "policyAttributes": [
   {
     "name": "myPolicy",
     "displayName": "Policy",
     "description": "Policy to be validated",
     "type": "String",
     "required": true
   },
   {
     "name": "myRule",
     "displayName": "Rule",
     "description": "Rule to validate",
     "type": "String",
     "defaultValue": "allow",
     "required": true
   }
 ],
 "applicableFlows": [
   "request"
 ],
 "supportedGateways": [
   "Synapse",
   "ChoreoConnect"
 ],
 "supportedApiTypes": [
   "HTTP"
 ]
}

You can upload the created custom policy from the WSO2 API Manager Publisher Portal as a custom or API-specific policy and attach it to an API resource.

Top