Signing messages is a technique that can be used in a number of contexts. For so-called “webhooks”, using signatures can help protect recipients of calls from bad actors.
A common technique is defined by a W3C recommendation, using a X-Hub-Signature HTTP header to hold a hash of the HTTP body. It appears there is an ad hoc convention, used by GitHub and others, using a variation of the header named X-Hub-Signature-256 which apparently is intended to indicate the sole use of SHA-256 as the algorithm.
I’m hoping someone in the community has set up something either in API Gateway or Integration Server that will verify a call from an application (such as GitHub) using this signing technique. Whether through built-in policy on API Gateway, the Enterprise Gateway Server mode of API Gateway, or Integration Server components. I’m hoping I’ve missed an included feature in my search of the docs so that I don’t need to create custom elements to support this.
The environment has API Gateway (on its local IS of course, DMZ and internal) and Integration Server internally. All 10.11.
Anyone implemented this that is willing to share info/experience/gotchas?
(Text added to bypass the duplicate post feature of the forum – I mistakenly created this in feature requests. Deleted it but the forum software still sees this as a dupe.)
@reamon This is a good callout. I have implemented webHook with just IS (using a HMAC validation) in webMethods Flow + Java. Issue (or limitation) is that the top-level flow service had to be anonymous and will get invoked. It would need to do validation and then if it passes call to 2nd Flow service. As we did not have any API Gateway (Pure IS only), policy based validation was not available.
It would be good for SAG to make Policy based validation available at IS layer - as that would prevent the flow service from being executed.
Thanks for the info! If it turns out there isn’t anything available yet, sounds like a candidate for the new features forum or the Ideas portal.
My current thinking at this point is to do a custom extension in the Identify & Authorize policy, to call out to an IS service (on the local GW IS) to do the check. Basically what you’ve done in IS, hooked up to the API GW policy.
Hi guys,
WebSub seems to a popular mechanism to replace server polling, I just wonder if many webMethods customers/prospects are adopting it in relation to tradition integration.
regards,
John.
This is but one data point, but we’re not adopting WebSub in its entirety. Indeed, the only thing we’re looking at right now is the convention of signing the HTTP body. And possibly one or 2 other security aspects (guard against replay, etc.)
Conceptually, “web hooks” have been around a long time under various monikers such as callouts, callbacks, notifications, outbound messaging, etc. We try to avoid polling when reasonable – constant polling when the answer to the question “do you have anything” is “no” 99% of the time just fills up logs and creates noise.