一种基于互联网的系统间安全调用接口实现方法与流程

本发明属于软件技术领域，具体涉及一种基于互联网的系统间安全调用接口实现方法。

背景技术：

随着互联网技术的日新月异的发展，以及电子商务在各领域的深度渗透，各互联网系统间相互取长补短、相互进行系统调用已成为常态。

在一个典型的基于HTTP或HTTPS对外提供服务的互联网系统中，接口的设计好坏会在很大程度上决定着该系统的推广，进而影响其商业价值。一个优秀的系统接口协议，需要适应不断变化的接口变更需求，还要保证接口调用的安全性，以保障用户数据的安全可靠。

一般的站点，其接口的设计遵循着从无到有、从简单到复杂的演变的过程。在日益变化的互联网时代，对用户有价值的站点往往其需求也是不断迭代变化的，一成不变的互联网系统是很少的。在互联网的这种基本特性下，传统的接口设计方式常常会遇到一些棘手的问题。

一方面，互联网系统的接口会提供基于HTTP或HTTPS协议的接口。为了满足需求的迭代，需要按照具体需求在原有接口的基础上进行增、删、改。而在对这些接口的改造过程中，不可避免地会遇到新改造的接口影响到原有接口调用这样的情形，这时，就需要让原有的接口调用方配合改造。这既不方便，也难以保证接口升级的平滑过渡。甚至有的时候并不可行，这是因为按照契约精神，在合同的约束下我们是无法对对方的行为进行干涉的，如果变更接口变得不可行，那就得沿用旧习，让新的需求在旧的接口体系中完成适配，而这往往会最终导致系统难以扩展。

另一方面，如果是涉及交易、支付、用户数据安全等场景，接口协议在安全性方面就需要提供更高的保障措施。一般采用基于公私钥签名/验签方式来提供防篡改、抗抵赖、数据完整性等方面的机制。签名机制的基本原理是将全部请求或部分请求参数按照事先约定好的顺序和格式进行拼接，然后将拼接好的数据做为签名的源串进行签名操作。这在实际运用中，不可避免地会遇到如下问题：1、调试困难；由于接口的提供方、调用方之间存在跨系统、跨公司甚至跨国间的沟通障碍，针对签名源串的格式，往往需要多次沟通和尝试，如各字段的顺序、大小写、是否有空格等因素，均会导致不易发现的错误，造成验签失败。调试起来十分耗时，线上故障的解决周期也较长。2、接口可扩展差；一旦接口发生细微的变更，比如变更参数名、增减参数等，都需要通知已接入的所有接入方配套修改，并同时发布。平滑升级的难度和成本都极大。3、安全机制欠缺统一的接入方式。由于系统的架构各自不同，系统间的接口调用方式也是五花八门，安全手段也是不尽相同，有的基于RSA签名算法、有的基于标准MD5算法、有的基于加扰的MD5算法、有的基于DSA签名算法，如何让系统以一种灵活的方式尽量适配不同的接入方，便要求提供一种统一、灵活的协议方式。

技术实现要素：

为解决现有技术中存在的问题，本发明的目的是提供一种基于互联网的系统间安全调用接口实现方法，通过在接口调用端构造结构化的消息体正文，将所有繁杂且格式不一的消息参数封装为指定格式，经对消息内容整体加密，分配消息内容整体与接口调用端需求相匹配的签名算法，形成扩展性高且安全度高的消息体，按照“消息类型+消息体+签名字段”拼装完整的接口调用请求，由HTTP/HTTPS服务端发送；当接口提供端收到请求后，经对消息体加密解码和结构解码后，执行对消息参数整体的验签，经验签通过的消息参数整体，由接口提供端提取所有参数进行逻辑处理并反馈给接口调用端。本发明有助于提供端以更灵活、更安全的方式适配不同的调用端，实现接口升级的平滑过渡。

一种基于互联网的系统间安全调用接口实现方法，其特征在于，通过在接口调用端构造结构化的消息体正文，将所有繁杂且参数格式不一的消息封装为指定格式消息体，经对消息内容整体加密，分配消息内容整体与接口调用端需求相匹配的签名算法，形成扩展性高且安全度高的消息体，按照“消息类型+消息体+签名字段(即消息参数整体)”拼装完整的接口调用请求，由HTTP/HTTPS服务端发送；当服务端即接口提供端收到客户端接口调用请求后，经对消息体加密解码和结构解码后，执行对消息参数整体的验签，经验签通过的消息参数整体，由接口提供端提取所有消息参数进行逻辑处理并反馈给接口调用端，具体步骤包括：

步骤1：客户端在发送调用请求前，获取并收集接口调用请求中所涉及的全部业务请求涉及的消息参数；

步骤2：集成所有获取到的业务请求的消息参数，以封装的方式构造消息体正文，并配消息体正文以指定的消息体格式；消息体格式具体为按照客户端和服务端之间约定的格式，集合所有零散的请求参数为一个完整的消息体，所述完整格式的消息体包括消息正文和消息格式；经构造结构化的消息正文中包含有能唯一识别客户端身份的标识；

特别地，消息体正文中包含所有业务请求参数，且参数排列顺序、参数格式和数量均不做限制，以减少参数调试的次数，避免因参数错误而导致的接口调用失败；

步骤3：按照客户端和服务端之间约定的规则，以消息体作为一个整体执行对称加密，屏蔽消息体正文中可见的字符串，使消息体中所有可读字符串转化为不可直接阅读的编码，避免直接在网络中传输明文；

步骤4：针对消息体中参数存在的特殊字符，为保证接口提供端能正确理解消息体中的特殊字符，利用URLEncode对特殊字符执行编码，形成以消息体为整体的加密消息；

步骤5：客户端利用步骤3形成的加密消息作为签名源，按照消息正文中的客户端标识在密钥管理模块中提取该标识对应的签名类型和密钥，进而调用与签名类型相匹配的签名算法，形成依赖于加密消息整体的签名字符串；

特别地，签名算法能因接口调用端的需求进行适配，保证客户端能以多种类的安全方式接入被请求端；

步骤6：按照“消息体正文+消息体格式+签名字段(字符串)”，客户端提取加密消息内容和签名字符串内容，拼接完整的接口请求，经由HTTP/HTTPS协议发送至服务端；加密消息内容指作为一个整体执行对称加密的消息体；

步骤7：接口提供端即服务端接收到请求后，依次完成对消息体的解码，提取消息体正文中包含的客户端标识，在服务端密钥管理模块中获得与该客户端标识匹配的预设的签名类型和私钥；具体为：

步骤7-1：服务端自动利用URLDecoder解码消息体，显示消息体正文中的特殊字符供服务端解析理解；

步骤7-2：服务端按照步骤3中客户端使用的加密规则，执行对消息体正文的解码，显示消息体正文中的明文字符；

步骤7-3：服务端按照步骤2中客户端使用的格式规则，解析消息体正文，获取消息体正文中所有的请求参数；

步骤7-4：提取请求参数中“客户端标识”参数；

步骤8：服务端验证客户端请求的合法性和请求消息的正确性；具体为：根据步骤7-4提取的客户端标识获得签名类型和密钥，以经步骤7-1解码后的消息体正文整体作为签名源，以步骤5中的签名字符串为签名报文执行验签操作；消息体验签成功后，服务端提取步骤7-3中的所有请求参数，根据接口的逻辑执行参数的验证，并执行接口处理逻辑；经处理的结果返回至客户端，接口调用请求完成。

步骤8中通过验证消息体的整体，验证客户端请求的合法性和请求消息的正确性，具体包括：

步骤8-1：按照客户端身份标识，获取与该身份标识相匹配的签名类型及密钥；

步骤8-2：以被请求端即服务端经URLDecoder解码后的消息体为整体作为签名源，以步骤5中的签名字符串为签名报文执行对消息体整体的验签操作；

若(1)被请求端对消息体整体进行验签及Base解码，且最终被请求端得到调用请求中所有业务参数，接口状态返回“成功”，表明验签成功，转步骤8-3；

若(2)被请求端不能对消息体整体准确验签，且最终网站B服务器获取“本次验签出错的具体错误类型”，接口状态返回“失败”，表明验签失败，转步骤8-4；

步骤8-3：被请求端提取经成功验签解码的所有业务请求参数，根据接口逻辑对所有业务请求参数进行验证及处理，并将处理结果反馈至请求端；

步骤8-4：被请求端构造失败的响应报文，返回至请求端。

所述签名算法能根据接口调用端的需求及接口调用方和接口提供方的约定，以多元化的方式任意适配消息体进行适配，保证客户端能以多种类的安全方式接入被请求端。

所述消息体正文中包含所有业务请求参数，且参数排列顺序、参数格式和数量均不做限制，以减少接口调用过程中参数调试的次数，避免因参数错误而导致的接口调用失败。

消息体内任一参数的增加、删除及修改，不会影响签名及验签随参数变化而发生变更，解决因“提高安全性而增加参数量”带来的验签困难。

本发明与现有技术方案相比，有益效果为：

(1)本发明通过将所有业务请求参数封装为一指定格式的消息体，有效解决传统的参数拼接方式中灵活性差且扩展难的问题，保证调用接口的变化不影响已完成接口对接用户的正常使用；

同时本发明不严格设定消息体内参数的格式、排序及数量，减少因个别参数的排序位置出错、拼写有误等问题而导致整个验签过程失败，协助客户端以更灵活的方式接入接口提供方；

(2)本发明提供将零散且数量多的参数以一个消息体整体参与签名和验签过程，并能根据接口调用方和接口提供方的约定，任意适配消息体以多元化的签名算法，消息体内任一参数的增加、删除及修改，不会影响签名及验签随参数变化而发生变更，有效解决因“提高安全性而增加参数量”带来的验签困难。

附图说明

图1为本发明实施例中网站A调用网站B的接口的示意图；

图2为本发明实施例中客户端构造消息体的流程示意图；

图3本发明构造的消息体构造方式与传统消息参数组合方式的对比图；

图4为本发明实施例中消息体在接口调用两端处理的流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。

本发明提供一种基于互联网的系统间安全调用接口实现方法，通过在接口调用端构造结构化的消息体正文，将所有繁杂且格式不一的消息参数封装为指定格式，经对消息内容整体加密，分配消息内容整体与接口调用端需求相匹配的签名算法，形成扩展性高且安全度高的消息体，按照“消息类型+消息体+签名字段”拼装完整的接口调用请求，由HTTP/HTTPS服务端发送；当接口提供端收到请求后，经对消息体加密解码和结构解码后，执行对消息参数整体的验签，经验签通过的消息参数整体，由接口提供端提取所有参数进行逻辑处理并反馈给接口调用端。

在本发明实施例中，网站A和网站B双向通信，网站A能调用网站B的接口，网站B能调用网站A的接口，图1为实施例中网站A调用网站B的接口的示意图；网站A通过组合所有业务请求参数为统一结构的消息体，构造接口请求数据，包括merchantid、userid、orderid，消息体经对称加密编码后作为构造签名字符串的依据，网站A将包含消息体的请求报文按照“http://website.com/api/query？加密后的消息体内容&签名字符&消息体格式”的方式发送至网站B解析，其中在发送前，须对“加密后的消息体内容”和“签名字符”中的特殊字符经URLEncoder处理。网站B按照双方约定规则验签、逐层解码消息体获取请求参数并执行逻辑处理，响应网站A的接口调用请求，并将逻辑处理结果返回至网站A；

图2为本发明实施例中客户端构造消息体的流程示意图，网站A在发送“查询订单详情”的接口调用请求前，获取并收集接口调用请求中所涉及的全部业务请求参数：客户端标识，即merchantId、订单id，即orderId、用户id，即userId，构造统一结构的消息体XML<商品id,订单id,用户id>，消除传统消息参数“格式不统一，排序及字母拼写严格”带来的验签难题，本发明实施例中构造的消息体与传统消息参数的对比图如图3所示：

客户端构造消息体的过程涉及如下具体步骤：

步骤201：集合接口调用请求中所涉及的全部业务请求参数，以封装的形式将所有零散的参数组合为一体，形成消息正文；其中，消息正文中包含所有业务请求参数，且参数排列顺序、参数格式和数量均不做限制；

步骤202：按照接口调用端和接口提供端之间约定的规则，配置消息正文的格式，形成一个具有XML格式的结构化消息体message1，具体如下

message1：

步骤203：在消息体message1中设置客户端唯一标示，用于接口提供端对调用者端的身份识别；

在本发明实施例中，以<merchantId>MER.200809300001</merchantId>作为接口调用者的身份唯一标示；

步骤204：采用Base64编码，执行对消息体message1整体的对称加密，形成消息体message2，具体如下：

message2：

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiID8+CjxtaWM+CiAgPG1lcmNoYW50SWQ+TUVSLjIwMDgwOTMwMDAwMTwvbWVyY2hhbnRJZD4KICA8dXNlcklkPnVyc3Rlc3QxMjM0QDE2 My5jb208L3VzZXJJZD4KICA8b3JkZXJJZD5PRC4yMDE2MDIwMjAwMDE8L29yZGVySWQ+CjwvbWljPg＝＝

从message1内容和message2内容比较看，加密后的message2屏蔽掉消息正文中可见的字符串，使消息体正文中所有可读字符串转化为不可直接阅读的编码，避免直接在网络中传输明文；

步骤205：采用URLEncode对特殊字符执行编码，消除消息体message2正文的参数中存在的特殊字符“＝＝”、“+”；经处理后的message3内容具体如下：

message3：

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiID8％2BCjxtaWM％2BCiAgPG1lcmNoYW50SWQ％2BTUVSLjIwMDgwOTMwMDAwMTwvbWVyY2hhbnRJZD4KICA8dXNlcklkPnVyc3Rlc3QxMjM0QDE2My5jb208L3VzZXJJZD4KICA8b3JkZXJJZD5PRC4yMDE2MDIwMjAwMDE8L29yZGVySWQ％2BCjwvbWljPg％3D％3D

图4为本发明实施例中消息体在接口调用两端处理的流程示意图，本发明实施例中的签名算法能因接口调用端的需求进行适配，保证网站A能以多种类的安全方式接入被请求端的网站B；当网站A构造完成XML格式的消息体后，执行对消息体整体的签名，并发送至网站B端，网站B进行围绕消息体的整体验签，涉及的步骤具体包括：

步骤401：网站A将加密后的消息体作为签名源，按照网站A的身份标识标签“<merchantId>”，从密钥管理模块中提取与身份标识相对应的签名类型RSA和密钥；

步骤402：根据网站A需要的签名类型和密钥，调用与签名类型匹配的签名算法RSA，生成依赖消息体message2整体的签名字符signature＝RSA(message2)，内容具体如下：

signature：

i/MAOx8cuETdesugMtBkkMGOB1cwf3IvrPqFpvLdrW7Z0UiXFrStvCWjjDujU6hDrgNcqQTPXMWU/pUbRBTuzbh7yU0IMlufwaDr+++r8EsF5szLhUOh/td7qogcmROTlplwrxAG3msoNTg4T8gm/mqigc/Vt+gOqumQlLjc9hQ＝

步骤403：由于signature中也存在特殊字符“+”及“＝”，采用URLEncode对特殊字符执行编码，经处理后的signature1内容具体如下：

signature1：

i％2FMAOx8cuETdesugMtBkkMGOB1cwf3IvrPqFpvLdrW7Z0UiXFrStvCWjjDujU6hDrgNcqQTPXMWU％2FpUbRBTuzbh7yU0IMlufwaDr％2B％2B％2Br8EsF5szLhUOh％2Ftd7qogcmROTlplwrxAG3msoNTg4T8gm％2Fmqigc％2FVt％2BgOqumQlLjc9hQ％3D

步骤404：按照网站A和网站B约定的网络协议，网站A将消息体message2、签名字符signature及接口前缀拼装成完整的HTTP请求参数，并利用HTTP标准的POST协议，发送HTTP请求至网站B；

按照URL的拼装格式

“http://website.com/api/query？msg＝message3&signature＝sign2&type＝xml”，网站A向网站B的请求内容具体如下：

http://website.com/api/query？msg＝PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiID8％2BCjxtaWM％2BCiAgPG1lcmNoYW50SWQ％2BTUVSLjIwMDgwOTMwMDAwMTwvbWVyY2hhbnRJZD4KICA8dXNlcklkPnVyc3Rlc3QxMjM0QDE2My5jb208L3VzZXJJZD4KICA8b3JkZXJJZD5PRC4yMDE2MDIwMjAwMDE8L29yZGVySWQ％2BCjwvbWljPg％3D％3D&signature＝i％2FMAOx8cuETdesugMtBkkMGOB1cwf3IvrPqFpvLdrW7Z0UiXFrStvCWjjDujU6hDrgNcqQTPXMWU％2FpUbRBTuzbh7yU0IMlufwaDr％2B％2B％2Br8EsF5szLhUOh％2Ftd7qogcmROTlplwrxAG3msoNTg4T8gm％2Fmqigc％2FVt％2BgOqumQlLjc9hQ％3D&type＝xml

步骤405：网站B的服务端接收到网站A发送的HTTPS请求，自动对请求中的消息体message3进行URLEncode解码，获得消息体message2；

步骤406：网站B按照网站A的加密规则，利用Base64解码，解析消息体message2，显示消息体message2中的明文，获得消息体message1；

步骤407：按照消息体message1的格式，解析消息体message1，提取message1正文中的身份标识字段<merchantId>内容，获得身份信息：MER.200809300001；

步骤408：按照身份标识，从密钥管理模块中获得与该身份标识相匹配的签名类型在本发明实施例中的签名类型是RSA；

步骤409：以消息体message2的整体作为签名源，以签名字符串signature为签名报文执行验签操作；若验签成功，转步骤410，否则转步骤411；

在本发明实施例中，在网站B服务端正常响应的情况下，若能对消息体message2的整体进行验签及Base解码，且最终网站B服务器得到“查询订单详情”接口请求中所有业务参数，接口状态返回“成功”，表明验签成功。

在本发明实施例中，在网站B服务端正常响应的情况下，由于signature存在问题，不能对消息体message2准确验签，且最终网站B服务器获取“本次验签出错的具体错误类型”，接口返回状态为“失败”，表明验签失败。

步骤410：网站B提取经成功验签解码的所有业务请求参数merchantId、userId、orderId，根据接口逻辑对所有业务请求参数进行验证及处理，并将处理结果反馈至网站A；

步骤411：网站B构造失败的响应报文，返回至网站A。