Hi @gonzalo.silva.cruz
I can see three possible ways of implementing this:
- Use G2O nginx module on Apigee infrastructure
- Use Java callout to validate signatures
- Use an external service (e.g. an external nginx or F5) to validate signatures
For item 1 - If this is in cloud, I'd doubt that Apigee will be able to host and maintain such custom nginx modules specific to your organization. This will also create road blocks for Apigee engineering and operations teams during regular component updates.
For item 2 - G2O implementation mostly relies on conventional crypto functions (MD5 or HMAC). Therefore it is possible, albeit a little difficult, to implement this in Apigee proxies as Java callout. I don't know of any official SDKs released by Akamai but if there is code already, we can look at using them. Performing this computational logic in Apigee proxies might contradict your need of "not allowing unknown consumers to be able to potential overload the entry infrastructure" - as such implementation might overload apigee infrastructure more than simple pass through depending on CPU usage of your existing apigee implementation.
For item 3 - Another approach is to pass G2O headers through Apigee to the target and use another component (nginx, f5) on target end to perform the validation. There are G2O modules for F5 and nginx. Taking this logic one step forward, you could implement a service callout, passing the signature headers, on request preflow making a dummy request to a specific nginx or F5 cluster on target side to validate signatures.
LinkedIn
Twitter
