Webhook端口中的自签名身份验证

概述

有时,可能需要通过 Webhook 端口从交易伙伴处接收数据,但该交易伙伴可能需要更多的安全性,而不仅仅是用于验证入站 Webhook 请求的基本身份验证用户名/密码 -- 或者您可能只想在入站 Webhook 消息上添加额外的安全层。

使用 Webhook 端口的自定义响应功能,您实际上可以创建自己的 HTTP 签名身份验证逻辑,通过使用分配给请求标头的 HMAC 签名值,对入站 Webhook 请求执行一些额外的身份验证。

Script脚本

这个脚本是我在这篇文章附带的 Webhook 端口的 Response 事件中编写的脚本:

复制代码
<!-- setting the secret key value to be available globally -->
<arc:set attr="secret.key" value="test" />
 
<!-- specifying the HMAC format, key value, algorithm, bits and output to result in HMACSHA256 -->
<arc:set attr="encIn.format" value="HMAC" />
<arc:set attr="encIn.hmackey" value="[secret.key]" />
<arc:set attr="encIn.hmacalgorithm" value="SHA" />
<arc:set attr="encIn.hmacbits" value="256" />
<arc:set attr="encIn.outformat" value="HEX" />
<!-- setting the data that should be included in order to create the hash. this is the body of the request -->
<arc:set attr="encIn.data">[_message.body]</arc:set>
 
<!-- generating signature HMAC hex digest hash -->
<arc:call op="encEncode" in="encIn" out="encOut">
  <arc:set attr="calculated.signature" value="sha256=[encOut.encodeddata]" />
  <!-- comparing the signature on the request to the signature calcuated above -->
  <arc:if exp="[_httpheaders.X-Hub-Signature-256 | equals([calculated.signature | tolower()])]">
    <arc:set attr="_response.write"><Status>Success!</Status></arc:set>
    <arc:set attr="_response.statuscode" value="200" />
    <arc:set attr="_response.statusdescription" value="OK" />
    <arc:else>
      <arc:set attr="_response.write"><Status>The signature provided in the request did not match the expected signature. The expected value is [calculated.signature | tolower()]</Status></arc:set>
      <arc:set attr="_response.statuscode" value="401" />
      <arc:set attr="_response.statusdescription" value="Unauthorized: Signature Mismatch" />
      <arc:throw code="500" desc="The signature provided in the request did not match the expected signature. The expected value is [calculated.signature | tolower()]" />
    </arc:else>
  </arc:if>

下面提供了有关与此脚本关联的部分的进一步说明,但上面脚本的每个主要部分都包含一个注释,概述了该脚本部分正在执行的操作。点击了解此处使用的主要 ArcScript 操作

实现

GitHub 的 webhook 请求的工作方式是,每次我的一个存储库发生推送事件时,它都会向配置的 API 端点(在本例中为知行之桥EDI系统的 Webhook 端口)发送 POST 请求。这只是特定于 GitHub,但这里的想法可以转移到任何其他自动化系统,甚至是能够发送 REST 请求的自定义实现。

出于测试目的,我的"秘密"只是一个简单的"测试"字符串。

推送事件发生后,GitHub 会向 URL 发送一个包含一些 JSON 数据的 POST。GitHub 使用 POST 的密钥和正文计算 HMAC 十六进制摘要,并将其作为标头 (X-Hub-Signature-256) 包含在内。

此请求到达 Webhook 端口后,自定义脚本实际上会使用传入请求的密钥和截获的正文生成相同的 HMAC 十六进制摘要,将其与 X-Hub-Signature-256 标头中包含的内容进行比较,然后根据结果创建适当的响应。

如果签名匹配,则接受请求,并将 200 OK 返回给 GitHub(即客户端):

如果签名不匹配,则请求在 Webhook端口的"输出"选项卡中显示为"错误",并在返回给客户端 (GitHub) 的响应中显示为 500 错误:

成功的请求在 Arc 中显示为"成功":

此外,对于失败的请求,可以直接在日志文件中看到 arc:throw 引发的自定义错误:

2022-11-30T19:47:57.468\] \[Error\] The signature provided in the request did not match the expected signature. The expected value is sha256=26bf09c078ddcf555a6a7cbd362c70e18e7233d0e4cfb056d2e00bc3ba8ee5e4 了解更多关于[Webhook](https://demo.z.kasoftwarecloud.com:28888/help.rst#Webhook "Webhook")的信息。 了解更多 EDI 相关信息,请阅读:[EDI是什么?](https://www.kasoftware.com/edi.html "EDI是什么?") [阅读原文:Webhook端口中的自签名身份验证](https://www.kasoftware.com/kb/2023/11/13/webhook-authentication.html "阅读原文:Webhook端口中的自签名身份验证")

相关推荐
北京聚信万通科技有限公司6 天前
汽车供应链–零部件厂商通过EDI对接主机厂全流程指南
安全·汽车·edi·电子数据交换·as2·oftp2
易连EDI—EasyLink15 天前
易连EDI–EasyLink实现OCR智能数据采集
网络·人工智能·安全·汽车·ocr·edi
知行EDI19 天前
HFI EDI 对接全指南:基于知行之桥实现 X12 报文自动化交换
edi·知行软件·知行edi·汽车edi
北京聚信万通科技有限公司21 天前
Odette国际组织为北京聚信万通科技有限公司颁发官方授权书
科技·edi·as2·国产软件·oftp2·odette
七夜zippoe24 天前
OpenClaw Webhook 与 Hooks 机制详解
人工智能·架构·webhook·hooks·openclaw
知行EDI25 天前
Wakefern EDI 对接指南:食品零售供应链的数字化合规路径
edi·知行之桥·零售·知行软件·知行edi·wakefern edi
易连EDI—EasyLink1 个月前
易连EDI EasyLink:新OFTP2安全算法 RSA-PSS、RSA-OAEP、SHA3-512筑牢企业EDI传输安全防线
网络·人工智能·安全·edi·电子数据交换·as2
知行EDI1 个月前
ZKW-Group EDI 对接完整指南 | VDA 4905/4913 报文与 OFTP2 配置详解
知行之桥·知行edi·汽车edi·zkw-group edi
知行EDI1 个月前
opmobility EDI 对接完整指南:汽车照明供应商数字化供应链实施方案
汽车·edi·需求分析·知行之桥·知行软件·知行edi
北京聚信万通科技有限公司1 个月前
北京聚信万通科技有限公司获Odette CA官方授权,成为中国区“Odette ID及数字证书”官方注册审批管理机构
网络·科技·汽车·edi·电子数据交换·国产软件