博客的网站页面设计,2008 iis配置网站,广州市 网站建设建设,淘宝基地网站怎么做本文简要概述如何在知行之桥EDI系统中使用 HTTP 签名身份验证#xff0c;并将使用 CyberSource 作为该集成的示例。
API 概述
首字母缩略词 API 代表“应用程序编程接口”。这听起来可能很复杂#xff0c;但真正归结为 API 是一种允许两个不同实体相互通信的软件。自开发以…本文简要概述如何在知行之桥EDI系统中使用 HTTP 签名身份验证并将使用 CyberSource 作为该集成的示例。
API 概述
首字母缩略词 API 代表“应用程序编程接口”。这听起来可能很复杂但真正归结为 API 是一种允许两个不同实体相互通信的软件。自开发以来API 已迅速成为全球企业、行业和服务使用的常用通信方法。
知道了这一点知行之桥EDI系统在构建时就考虑到了 API。使用应用程序中的专用端口用户可以设计和创建从公共 API 端点或基于 REST 的 API 发送和接收数据的流。在实践中大多数如果不是全部RESTful API目前都使用HTTP作为传输层因为HTTP的基础设施、服务器和客户端库已经被广泛使用。
这些流可以通过使用知行之桥EDI系统的许多专用端口中的几个来实现。这些端口允许用户指定他们希望面向哪个 API 端点以便 POST 某些 JSON 数据或提交 GET 请求以接收特定报告。但是当 API 需要 HTTP 签名身份验证等身份验证方法时它可能会变得有点棘手。使用此方法在知行之桥EDI系统中发送适当的请求需要的不仅仅是拖放和操作稍后将更详细地解释。
HTTP签名认证是什么以及如何使用
商业 API 通常需要某种形式的安全性以便不是任何人都可以访问他们可以提供的数据。保护 API 的最常见方法是使用共享密钥。每次调用 API 时都必须提供此密钥。但是此方法不提供确保所传输数据完整性的方法。在这些情况下HTTP 签名身份验证允许提高 API 的安全性。
HTTP 签名身份验证通常以两种不同的方式使用。 允许发送方通过证明他们拥有密钥来请求访问资源。 允许发送方确认发送的邮件内容正确无误并且在传输或存储过程中未被更改。
以 CyberSource API 为例。API 文档要求 REST HTTP 请求必须包含您发送给 CyberSource 的签名请求标头。此签名由发送方加密并在 API 收到时解密以确保发送请求的用户有权访问指定的资源。
在知行之桥EDI系统中这可以通过使用 REST 端口和脚本端口来实现该脚本包含自定义脚本该脚本为 HTTP 签名生成所需的标头和加密。然后脚本端口将这些消息标头发送到 REST 端口然后 REST 端口使用这些标头包括签名来处理 REST 请求。
REST 端口
REST 端口允许用户使用 HTTP 协议与交易伙伴发送或接收数据其操作与 Postman 非常相似。用户及其客户端都可以建立一个公共 API 端点双方都可以从该 API 进行 POST 或 GET 数据。
将 REST 端口拖放到工作流中时设置页面将打开并显示如下所示的内容。 此处应提供有关要与之交互的 API 的详细信息例如请求方法和唯一的 API 端点 URL、身份验证以及所需的任何自定义标头。如果 API 需要也可以提供服务器身份验证凭据。
但是如果 API 要求在所有请求中使用 HTTP 签名身份验证该怎么办以 CyberSource 为例其 API 要求使用 HTTP 签名身份验证发送所有请求。
在 REST 端口中使用 HTTP 签名身份验证比在端口设置中创建消息头、提供 URL 然后提交请求要复杂得多。主要区别在于如何获取加密的签名字符串作为 REST 端口中的消息标头传递。这就是自定义脚本和Script端口发挥作用的地方。
CyberSource API
CyberSource API 是一个非常大型的业务 API专为作为电子商务信用卡支付系统管理公司运营的公司而开发。他们的 API 允许用户执行诸如处理付款、管理发票以及在此用例中报告等操作。
本文中的所有 API 参考都可以在 CyberSource API 文档中找到该文档位于此处。 https://developer.cybersource.com/docs/cybs/en-us/tms/developer/all/rest/tms-developer/intro.html
如果使用本文通过知行之桥EDI系统实现 CyberSource API请花时间确保您已创建并按顺序创建所有必要的凭据和密钥。
此示例所需的两个密钥是 Encoded Secret Key 和 Secret Key in UUID Format。这两个密钥都可以在 CyberSource 商务中心内找到网址为https://ubctest.cybersource.com/ebc2/
Script 端口
在了解了 CyberSource 的要求以及知行之桥EDI系统如何处理这些要求之后是时候介绍Script 端口了。此端口允许您生成签名字符串并将其作为消息标头传递到流中的 REST 端口。概括地说Script 端口中的过程如下所示 创建解码密钥的字节数组在 CyberSource Business Center 中生成。 创建一个基于解码的密钥字节数组的 HMACSHA256 对象然后使用此 最后从上一步中 HMACSHA256 对象的字节数组生成一个 base-64 编码的字符串。
使这变得棘手的是加密的签名字符串以及密钥 ID、签名算法和标头名称构成了签名标头的实际值。但是所有这些都可以在Script 端口中使用 ArcScript 来完成。
示例工作流
在介绍了一般 API 信息、HTTP 签名以及如何在此过程中使用知行之桥EDI系统之后现在是时候转向使用 CyberSource API 的示例 HTTP 签名身份验证流程了。强烈建议在继续之前下载知行之桥EDI系统并导入此工作流。
示例工作流由 Script 端口和 REST 端口组成。 分解
CyberSource API 要求在请求中传递特定的 HTTP 标头。这些标头是 v-c-merchant-id v-c-商家 ID Date 日期 Host 主机 Signature 签名
v-c-merchant-id、Date 和 Host 是直截了当的。但是签名标头是它变得更加复杂的地方。
Signature 标头由多个名称-值对或参数组成由 keyid、algorithm、headers 和 signature 组成。标头名称-值对只是所有必需标头的字符串而签名名称-值对是哈希签名它是标头字段及其值的 base-64 哈希编码。
通过将这些 HTTP 标头连接在一起形成一个字符串并使用具有共享密钥的对称算法 hmac-sha256 获取该字符串的加密哈希值从而生成 HTTP 请求的数字签名。最后对加密的字节进行base-64编码得到签名字符串。
下面的代码块显示了使用 CyberSource API 时生成的 HTTP 签名标头的示例。如上所述签名标头由多个名称-值对组成签名名称-值对包含上述 base-64 编码的签名字符串。
v-c-merchant-id: mymerchantid
Date: Fri, 12 Jul 201900:44:13 GMT
HOst: apitest.cybersource.com
Signature: keyid6d75ffad-ed36-4a6d-85af-5609185494f4, algorithmHmacSHA256, headershost date (request-target) v-c-merchant-id, signatureeQkzhzu
脚本编写
了解 Script 端口以及它如何利用 HTTP 签名身份验证后是时候更深入地挖掘脚本本身并了解脚本编写过程的每个步骤中发生的情况了。
专为 CyberSource API 设计的 HTTP 签名身份验证脚本可分为四个主要部分。 解码编码的密钥 将十六进制密钥暂存为 Base-64 编码的HMACSHA256哈希 设置邮件头 生成哈希签名
接下来的四个部分将更详细地介绍这些步骤。
解码编码的密钥
脚本中的第一步是从 CyberSource Business Center 获取的解码密钥设置为脚本中的项目。然后使用 encDecode 操作将该编码的密钥解码为十六进制值。
使用 encEncode 或 encDecode 操作时可以使用“informat”和“outformat”属性指定输入和输出格式。默认的格式是 base64这是原始密钥在这里编码的所以在这种情况下不需要指定格式。但是outformat 已设置为“HEX”。
在这种情况下此操作还需要一个“in”项然后需要一个指定的“out”项。这是指将哪个项目传递到操作中以及操作完成处理后输出项目的所需名称。
此过程的最后一步是将解码的密钥现在为十六进制值设置为全局项以便它可以在脚本范围内的任何位置使用。十六进制值必须以“0x”为前缀以告知分析引擎它正在处理常量而不是标识符或保留字。然后此十六进制值稍后用于创建 base-64 编码的HMACSHA256哈希。
!-- encoded secret key in base64 encoding to HEX --
arc:set attrencodedKey.data valueJIVAFb/fO0WmocDuc3EvSjNiye7tif/ajSTWdFi/sU/
arc:set attrencodedKey.outformat valueHEX/
!-- setting decodedGlobal and setting value to hex key to be available globally --
arc:set attrdecodedGlobal.data value /
arc:call opencDecode inencodedKey outdecodedKey
arc:set attrdecodedGlobal.data value0x[decodedKey.decodeddata] /
/arc:call
将编码的密钥暂存为 base-64 编码的 HMACSHA256 哈希
脚本中的下一步是为后续步骤做准备。在脚本结束时必须将每个标头字段名称的字符串及其关联值以及十六进制键编码为 base-64。在此步骤中必须设置要编码的输入数据 encIn 的参数。必须在此处指定输入格式、hmackey、算法、位数和输出格式。
然后此数据稍后将由 encEncode 操作处理其中将以 Base64 编码。
!-- encoding the hex key to HMACSHA256 --
arc:set attrencIn.format valueHMAC /
arc:set attrencIn.hmackey value[decodedGlobal.data] /
arc:set attrencIn.hmacalgorithm valueSHA /
arc:set attrencIn.hmacbits value256 /
arc:set attrencIn.outformat valueBASE64 /
设置消息头
配置解码的密钥和编码参数后现在可以将消息头添加到脚本端口中创建的消息中以便能够在 REST 端口中验证它们。
需要注意的一点是API 密钥在脚本的这一部分中定义但它也可以在之前的任何步骤中定义因为它在最后一节之前不会使用
在此处使用 arcset 关键字可以定义所需的标头例如 MerchantID、HeaderDate 和 HeaderHost。
!-- API secret key. this is the secret key in UUID format --
arc:set attrapiSecret.key valueb84ba2d7-1a4b-4814-b757-2f747ccab086 /
arc:set attrReport.Date value[_|utcnow(yyyy-MM-dd)] /
!-- Setting custom headers. Make sure you replace the merchant ID with your ID --
arc:set attrFileload.header:MerchantID valuensoft_test1 /
arc:set attrFileload.header:myCustomHeader value?organizationId[Fileload.header:MerchantID]reportDate[Report.Date]reportNametest /
arc:set attrFileload.header:HeaderDate value [_|date(r)] /
arc:set attrFileload.header:HeaderHost valueapitest.cybersource.com /
此处还定义了一个 myCustomHeader其中包含 MerchantID、报告日期和报告名称。创建此标头以便可以在 REST 端口的 URL 中将其作为查询字符串的一部分引用如下所示 https://apitest.cybersource.com/reporting/v3/report-downloads[_message.header:MyCustomHeader]
定义这些标头后可以在标头值字段中使用 _message.header 语法在 REST 端口中引用它们。 创建哈希签名
最后一步是创建哈希签名。这是用于验证消息内容或提交请求的实体的真实性的内容。如前所述数字签名是通过将所有 HTTP 标头连接在一起形成一个字符串来获得的。然后使用第二步中设置的 hmac-sha256 算法使用解码的密钥通过该字符串获取加密哈希值。最后所有内容都以 base-64 编码从而生成签名字符串。
此过程可以分为两个不同的部分 设置和连接标头 对标头字符串进行编码以生成签名字符串
使用 arcset 关键字将所有标头及其值连接在一起为一个字符串。在本例中将执行此操作并将其设置为 encIn 项要编码的项的 data 属性。在此步骤中特别是使用 CyberSource API标头字段的放置顺序必须与在消息标头中传递的顺序相同。
这里需要注意的一件事是包含一个名为“request-target”的标头。request-target 标头值是小写的 HTTP 谓词后跟空格然后是资源路径减去主机。以下示例显示了对“/reporting/v3/report-downloads”资源的 GET 请求。在请求目标值中包含查询字符串和请求 ID。在本例中已在 myCustomHeader 值中定义了查询字符串。
(request-target): get /reporting/v3/report-downloads[Fileload.header:myCustomHeader]
在这种情况下为每个单独的标头包含一个新行也很重要但不要在字符串末尾包含任何换行符 \n。
arc:set attrencIn.datahost: [Fileload.header:HeaderHost]
(request-target): get /reporting/v3/report-downloads[Fileload.header:myCustomHeader]
date: [Fileload.header:HeaderDate]
v-c-merchant-id: [Fileload.header:MerchantID]/arc:set
此块完成脚本中的最后两个进程。首先调用 encEncode 操作并将之前定义为 encIn 的所有数据作为操作的输入参数传入。输出在本例中定义为 encOut包含所有输入数据但现在它是 base64 编码的。
然后arcset 关键字用于创建由 keyid、algorithm、headers 和 signature 组成的签名标头。为了从 encEncode 操作访问编码数据必须引用输出项的“encodeddata”属性。
在这种情况下签名标头设置为 [encOut.encodeddata]其计算结果为实际编码的签名字符串。
成功的签名标头应如下所示
Signature: keyid6d75ffad-ed36-4a6d-85af-5609185494f4, algorithmHmacSHA256, headershost date (request-target)
v-c-merchant-id, signatureeQkzhzu8UHEQmpBTVMibdNpPw1aLunmY41ckyLKoOjs
!-- generating signature hash --
arc:call opencEncode inencIn outencOut
arc:set attrFileload.header:signaturekeyid[apiSecret.key], algorithmHmacSHA256, headershost (request-target) date v-c-merchant-id, signature[encOut.encodeddata]/arc:set
/arc:call!-- push the output --
arc:push itemFileload /
最后使用 arcpush 关键字将包含所有标头和签名的整个项目从脚本端口中推出。然后此文件将发送到 REST 端口在该端口中可以发出 HTTP 请求在本例中为 GET 请求。
结论
本文的目的是帮助了解知行之桥EDI系统是如何围绕 API 构建的以及它如何使用预构建的连接器和自定义脚本与 API 集成以及如何使用知行之桥EDI系统来遵守 API 的特定身份验证要求例如 HTTP 签名身份验证。
此脚本包含专为与 CyberSource API 集成而开发的 ArcScript我们提供的方式可以轻松操作以适应可能需要 HTTP 签名身份验证的许多其他用例。
了解更多 EDI 相关信息请阅读EDI是什么
阅读原文知行之桥EDI系统HTTP签名验证
