Integrating existing proxy with third party security system

v21
Bronze 2
Bronze 2

In Apigee Hybrid we are have a requirement of integrating our existing proxies with the third party security system. Wherein we need to send the request and response details of each proxies to that third party security system via javascript policy without effecting the actual traffic.

We are planning to enforce this functionality using flowhook's, so we wanted to understand if its a good approach (OR) there would be any issues due to the flowhook's.

0 3 141
3 REPLIES 3

It's a reasonable approach.  I've seen that approach taken for various purposes.

  • for an anti-virus / malware scanner. This is a "real time" scan,  so the transmission out to the external security system needs to be synchronous with respect to the API request. If the scanner deems the request to be harmful, the API proxy needs to reject the request "right now".  So the proxy must wait for the scan. 
  • For a big-data based bot-style scanner.  In these cases, the scan happens asynchronously w.r.t. the inbound API request.  The API won't behave differently, regardless of the result of the scan. 

In either case, it's a reasonable pattern.  There are some systems that are sort of a hybrid of the above - the scan is asynchronous, but there is a quick check on the inbound request to reject requests that match patterns of known bot traffic. 

Which pattern you use - sync vs Async - is a choice you should be aware of.  The synchronous scan will delay response to the inbound API request. The async scan can be done in the PostClientFlow, which won't delay response. To do that you can use ServiceCallout.  I think you may not be able to use JavaScript in the PostClientFlow?   But not sure if that restriction is still in place. 

v21
Bronze 2
Bronze 2

Hi @dchiesa1 ,

Thanks for your input.

To add on, the scan is done offline... as of now the the 3rd party system is just going to get a copy of the request/response and provides a report offline. In the future the approach to scanning might change

so in this scenario can we go with the FlowHook approach with the javascript policy.

you can do that.  Verify that JS can be used in PostClientFlow. 

My advice is to "stage" the content to be logged to the 3rd party (both request and response), by storing that content into a context variable.  and then send it to the aggregation endpoint, only after the client gets the response, in the PostClientFlow.

That's a well-used pattern.