CN109525394A - 用于认证网络消息的系统和方法 - Google Patents
用于认证网络消息的系统和方法 Download PDFInfo
- Publication number
- CN109525394A CN109525394A CN201810661056.XA CN201810661056A CN109525394A CN 109525394 A CN109525394 A CN 109525394A CN 201810661056 A CN201810661056 A CN 201810661056A CN 109525394 A CN109525394 A CN 109525394A
- Authority
- CN
- China
- Prior art keywords
- message
- client
- api
- certificate
- equipment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
提供了认证消息的网络和方法。一个示例性方法通常包括接收来自客户端的消息,其中消息包括客户端证书。该方法还包括通过应用程序编程接口(API)网关基于将计算设备识别为已识别计算设备的证书来验证计算设备,以及通过API网关基于客户端证书经由与储存库分开的全局访问管理器来验证客户端。该方法还包括,当计算设备和客户端被验证时使得指示客户端的安全令牌被生成,由此安全令牌指示客户端并且允许来自客户端的消息被递送到一个或多个后端服务。
Description
相关申请的交叉引用
本申请是2015年11月16日提交的美国专利申请号14/942,048的部分继续申请。上述申请的全部内容通过引用并入本文。
技术领域
本公开总体上涉及用于认证消息(例如,网络消息)的系统和方法,其包括认证来自客户端的消息,并且进一步认证消息传递所通过的计算设备。
背景技术
本节提供与本公开相关的背景信息,其不一定是现有技术。
支付网络被提供用于来自和去往客户端(诸如商家、收单方、发行方和其他实体)的各种不同类型的消息,并且进一步在某些情况下,在客户端之间传递各种不同类型的消息。因为这些消息通常包括敏感和/或机密数据,或寻求访问敏感和/或机密数据,所以已知的支付网络采用各种加密技术来保护数据,并且可以进一步规定用于向和/或从支付网络传递消息的安全条件。此外,已知支付网络采用安全分级结构,由此随着支付网络内不同网络部分或区域之间的消息传递的进展,需要持续认证消息以确保支付网络的安全性。
附图说明
这里描述的附图仅用于选定实施例而不是全部可能的实现方式的说明性目的,并且不旨在限制本公开的范围。
图1是本公开的示例性系统的框图,其包括适于认证发送到支付网络的消息的支付网络;
图2是可以在图1所示的示例性支付网络中使用的计算设备的框图;以及
图3是可以在图1所示的支付网络中实现的示例性方法,用于认证其中的消息传递。
贯穿附图的多个视图,对应的附图标记指示对应的部分。
具体实施方式
现在将参照附图更全面地描述示例性实施例。这里包括的描述和具体示例仅用于说明的目的,并不意图限制本公开的范围。
支付网络提供各种服务,这些服务可能涉及支付账户交易和/或交易数据的使用,这些服务依赖于内部和外部等的一个或多个其他实体(广义地,客户端)对支付网络的访问。通过支付网络从客户端接收消息的形式提供访问。如这里所述,每个消息包括安全证书,该安全证书由支付网络用来认证客户端。此外,这里的网络(例如,支付网络等)和方法在多个级别上认证消息(例如,应用程序编程接口(API)消息等)。特别地,当支付网络处接收到来自客户端的消息时,计算设备将客户端证书作为对象附加到消息,并且在将消息传送到API网关之前可选地进一步附加其自己的证书到消息。接下来,API网关基于API网关内的本地储存库(例如,由通信本身或通过附加到消息的证书,等等)或根据除了API网关之外的储存库来验证计算设备(API网关从计算设备接收该消息)的证书,并且进一步经由除API网关之外的全局访问管理器验证客户端证书,即附加对象。在多级认证时(例如,在客户端级别和计算设备级别等),API网关导致产生安全令牌,其表示客户端并且可在支付网络内使用以访问后端服务器和/或由后端服务器提供的服务。以这种方式,增强了安全性,以保持保护支付网络内的交易数据和其他数据免受未经授权的访问
图1示出了其中可以实施本公开的一个或多个方面的示例性系统100。虽然系统100的部分以一种布置呈现,但应该理解的是,其他示例性实施例可以包括例如另外安排的相同或不同的部分,例如,取决于对支付网络的消息传递的验证等。
如图1所示,所示系统100通常包括商家102、收单方104、支付网络106和发行方108,每个耦合到网络110。网络110可以包括但不限于有线和/或无线网络、局域网(LAN)、广域网(WAN)(例如因特网等)、移动网络和/或能够支持系统100的所示的两个或更多个部件之间的通信的另一合适的公共和/或专用网络,或其任何组合。在一个示例中,网络110包括多个网络,其中多个网络中的不同网络可由图1中所示的实体中的不同实体访问。在该示例中,网络110可以包括私人支付交易网络,该私人支付交易网络可由支付网络106访问收单方104和发行方108,以及单独地支付网络106和商家102可以借助其通信的网络(例如,通过基于web的应用程序等)。
一般来说,在图1中,商家102提供一种或多种产品(例如商品和/或服务等),以便销售给消费者。为了购买产品,消费者向商家102呈现支付设备(与支付账户相关联)。反过来,商家102、收单方104、支付网络106和发行方108合作,响应于消费者,使用消费者的支付账户完成产品的交易(广义地说,购买交易)。作为购买交易的一部分,商家102读取支付设备并经由网络110经由收单方104(与商家102相关联)向支付网络106传送授权请求以处理交易(例如,使用交换机等)。支付网络106又将授权请求传送给发行方108(与消费者的支付账户相关联)。然后,发行方108向支付网络106提供授权响应(例如,授权或拒绝请求),该授权响应通过收单方104(经由支付网络106)提供返回商家102。然后商家102与消费者的交易完成或不完成,取决于授权响应。如果交易完成,则购买交易稍后在商家102和收单方104之间由商家102和收单方104(根据结算安排等)清算和结算,以及在收单方104和发行方108之间由收单方104和发行方108(根据另一个结算安排等)清算和结算。
以上是对支付网络106的交易的简要描述,其被提供用于说明支付网络与其他实体的交互的目的。应该理解的是,在上述交易中多个消息被引导到支付网络106,并且随着交易受到附加服务的影响,其他消息可以被引导到支付网络106。例如,如果交易所针对的支付账户经受3D安全服务,则可以在授权交易之前将一个或多个附加消息引导至支付网络106(并且特别是其中的目录后端服务)以认证消费者。
此外,作为上述交易的一部分以及与之类似的多笔交易,在商家102、收单方104、支付网络106、发行方108和消费者之间生成交易数据。取决于交易,交易数据可以包括但不限于支付账户号码、商家ID、收单方ID、终端ID、分配给商家102(例如,通过支付网络106等)商家类别代码(MCC)、时间戳等。一旦产生,交易数据被存储在系统100的一个或多个不同实体中,具体而言是支付网络106(例如,在数据中心(未示出)或其他)。
交易数据还可以通过后端服务器和/或由其提供的服务112为支付网络106提供的各种服务提供基础。这样的服务可涉及例如欺诈保护、分析、市场洞察、奖励等。可将服务提供给图1中所示的实体或其复制品或其他部分,例如与图1的一个或多个实体合作的第三方。在3D安全示例中,认证实体可以包括一个或多个第三方,诸如商家插件(MPI)(如被指示为包括在图1中的商家102中和/或与其相关联)和/或访问控制服务器(ACS)(包括在发行方108中和/或与发行方108相关联)。每个都可用于实现3D安全协议,将消息发送到支付网络106,并从支付网络106接收消息,以便在购买交易之前认证消费者。应该理解的是,发送到支付网络106并且意图到达支付网络106处的后端服务器/服务112的消息可以针对由支付网络106提供的任何不同数量和/或类型的服务提供给图1中示出和未示出的实体。
如图1进一步所示,支付网络106包括一个或多个后端服务器112,后端服务器112被提供来托管由支付网络106提供的一种或多种后端服务。在该特定实施例中,(一个或多个)后端服务器112将多个API暴露给外部和/或内部客户端,通过其可以利用一个或多个服务。API可包括例如由万事达卡国际公司提供的以下示例性API中的一个或多个:保证IQAPI,其被配置为保证消费者使用真实属性进行数字交易;自动账单更新器(ABU)API,其被配置为减少由改变的账号和失效日期引起的无卡(CNP)交易拒绝;账单支付验证器API,其被配置为使用例如提供的远程支付和呈现服务(RPPS)系统来确定账户是否有资格进行账单支付;BIN表资源API;商家API的欺诈评分,其被配置为针对电子商务商家提供预测的基于行为的欺诈评分工具;位置服务API,其被配置为访问用于客户端应用程序和/或网站的ATM和商家位置的全球数据库;丢失和被盗账户列表API,其被配置为识别已被发行方报告丢失或被盗的卡;MasterCard SendTM API,其被配置为国内和跨境汇款;MasterpassTM API,其被配置为简化使用数字钱包的消费者的结账体验;MasterpassTM QRAPI;万事达卡数字使能服务(MDES)API,其被配置为围绕万事达卡号码标记化提供服务,以提高支付安全性;商家标识符API,其被配置为提供关于给定商家的信息;MoneySend API,其被配置为在账户之间转移资金并发送支出;支付网关服务(MPGS)API,其被配置为向商家和银行提供全球支付处理服务以及防欺诈和风险管理解决方案;Repower API,其被配置为向符合条件的支付卡添加现金;Spend Controls API,其被配置为管理以何方式、在何时、在何处使用付款账户,等等。也就是说,在其他实施例中,可以从(一个或多个)后端服务器112或其他计算设备提供其他API。
通常,由支付网络106提供的API可通过API网关114(例如,XML网关(例如,与RestAPI等相关联)、提供的ESB(企业服务总线)网关等等)以及耦合到API网关114的两个已识别计算设备116和118来访问。然而,应该理解的是,在其他实施例中,可以存在包括在支付网络106中的一个或多个附加计算设备和/或网关设备,例如,根据例如不同系统实施例的各个方面(例如,业务量、支付网络106的地理分布等等),这些附加计算设备和/或网关设备可以排列在中间计算设备122和(一个或多个)后端服务器112之间。
在该示例性实施例中,计算设备116和118均是网络路由器。并且,在这个示例中,计算设备116被配置为从商家102经由包括在发行方108中和/或与发行方108相关联的MPI以及还有包括在发行方108中和/或与发行方108相关联的ACS接收、提供和/或响应用于3D安全协议(例如,由提供的服务等)的验证消息。另外,计算设备118被配置成协调通常在支付网络106内部或外部去往/来自IPsec或其他安全协议、虚拟专用网络(VPN)的消息传递和去往/来自客户端的消息传递(经由DMZ计算设备,或者外围网络等),如图1中的虚的框/线所指示的。独特地,API网关114可以包括在API网关114的存储器中提供的本地储存库124,如图所示。本地储存库124包括仅专用于已识别计算设备116和118的证书验证数据,由此已识别计算设备116和118可以在API网关114内部进行验证而不必访问其他设备(例如全局访问管理器127等)(其他未识别计算设备不能在API网关114进行内部验证)。特别地,本地储存库124包括计算设备116和118的客户端证书的特异名称。然而,相反地,API网关114可以替代地依赖于API网关114外的储存库,诸如例如轻量级目录访问协议(LDAP)计算设备126和/或全局访问管理器127。
此外,如图1所示,支付网络106包括客户端与计算设备116之间的中间计算设备122。中间计算设备122通常包括路由器(例如,边缘路由器等),在该示例中,该路由器可以包括负载平衡和/或应用程序防火墙功能。在一些实施例中,计算设备122可以是数据中心(或IDC)F5计算设备。而且,在该示例性实施例中,支付网络106还包括两个附加计算设备。一个计算设备是支付网络106内的全局访问管理器127,其被配置为与作为数据储存库的LDAP计算设备126进行交互,用于内部和外部客户端的验证。并且,另一个计算设备是安全服务计算设备(SSCD)128,其被配置为生成在支付网络106内并且具体地由(一个或多个)后端服务器112和由其提供的服务接受的安全令牌。
虽然上述计算设备中的每一个被示为分离的,但在该特定实施例中,应该理解的是,在其他支付网络实施例中,某些计算设备可以集成在一起,或者进一步彼此分离或通常与支付网络106分离。此外,除了或代替图1所示的一个或多个计算设备,可以采用其他计算设备。例如,API网关114仅耦合到两个已识别计算设备116和118以接收客户端消息。应当理解,在其他实施例中,取决于例如(一个或多个)后端服务器112所提供的服务、客户端消息传递的量、支付网络拓扑结构等,不同数量的计算设备可以是针对API网关114的“已识别”计算设备。另外,虽然在图1中通过线“连接”示出了示例性消息流程,但应该理解,计算设备116和118以及中间计算设备122耦合到支付网络106内的网络(例如,类似于网络110等),由此每个能够在本实施例中彼此通信。以这种方式,如下面更多描述的那样,中间计算设备122例如能够将消息传递给计算设备118,例如以施加负载平衡操作等。
此外,虽然支付网络106被示为包括上述特定部分(针对该实施例),但系统100不限于支付网络106的这种地理布置和/或其他方式限于一个实体和/或一组计算设备。应该理解,支付网络106的部分可以包括在单个位置处的计算设备,但是也可以包括分布在地理区域上的计算设备。此外,可以通过由支付网络106使用的一个或多个云基服务来提供计算设备。然而,无论如何,配置和/或消息处理基本上与这里的描述一致。
图2示出了适用于系统100的示例性计算设备200。作为示例(而不是限制),示例性计算设备200可以适当地包括一个或多个服务器、工作站、计算机、路由器、网关或它们的组合等等。在(图1的)系统100中,商家102、收单方104和发行方108各自与计算设备200相关联或实现于计算设备200中。此外,(一个或多个)后端服务器112、API网关114以及计算设备116、118、120、122、126、127和128中的每一个可以与计算设备200一致。据此,应该理解,系统100不限于计算设备200,因为可以使用不同的计算设备和/或计算设备的布置。还应该理解,部件的不同部分和/或布置可以用在其他计算设备中。此外,在各种示例性实施例中,计算设备200可以包括位置紧邻或分布在地理区域上的多个计算设备。
参照图2,图示的计算设备200通常包括处理器202和耦合到处理器202的存储器204。处理器202可以包括但不限于一个或多个处理单元(例如,在多核配置等中),包括通用中央处理单元(CPU)、微控制器、精简指令集计算机(RISC)处理器、专用集成电路(ASIC)、可编程逻辑电路(PLC)、门阵列和/或能够具有在此描述的功能的任何其他电路或处理器。上述示例仅是示例性的,并不意图以任何方式限制处理器的定义和/或含义。
如本文所述,存储器204是使得诸如可执行指令和/或其他数据的信息能够被存储和检索的一个或多个设备。存储器204可以包括一个或多个计算机可读存储介质,诸如但不限于动态随机存取存储器(DRAM)、静态随机存取存储器(SRAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM)、固态设备、CD-ROM、磁带、闪存驱动器、硬盘和/或任何其他类型的易失性或非易失性物理或有形计算机可读介质。存储器204可以被配置为存储交易数据、证书、安全技术、安全令牌(例如,SAML令牌等)和/或适用于在此描述的任何其他类型的数据等,但不限于此。此外,在各种实施例中,可以将计算机可执行指令存储在存储器204中以供处理器202执行以使处理器202执行本文所述的一个或多个功能,使得存储器204是物理的、有形的、非瞬态的计算机可读存储介质。应该理解的是,存储器204可以包括各种不同的和/或分离的存储器,每个存储器都在本文描述的一个或多个功能或过程中实现。
另外,所说明的计算设备200包含耦合到处理器202(且在一些实施例中还耦合到存储器204)的网络接口206。网络接口206可以包括但不限于有线网络适配器、无线网络适配器、电信适配器或能够与包括网络110的一个或多个不同网络进行通信的其他设备。在一些示例性实施例中,计算设备200包括并入处理器202中或与处理器202合并的一个或多个网络接口206。
再参照图1,在该实施例中,支付网络106被配置为执行从例如商家MPI、其他外部客户端和/或内部客户端120(广义地,客户端)接收的消息的多级认证。在图1的示例性实施例中,在支付网络106中允许的消息是SSL消息,或者相互SSL(MSSL)消息,或者TLS消息或者相互TLS(MTLS)消息等。然而,应当理解,其他支付网络实施例可以包括其他的根据证书或其他方式提供安全性的不同类型的消息传递和/或协议等。
例如,在从商家MPI接收到消息时,中间计算设备122被配置为验证消息,将客户端证书(与发送消息的客户端相关联)作为对象(例如,作为证书对象等)附加到消息,然后经由计算设备116将该消息发送到API网关114,API网关114可选地将其证书附加到消息。类似地,在该实施例中,计算设备118被配置为针对从客户端120接收到的内部消息,可选地将客户端证书作为对象附加到消息并且进一步将其自己的证书附加到消息。通常,例如,当计算设备118终止消息时,计算设备118将其自己的认证附加到消息,并且生成另一消息到API网关114(例如,用于MTLS消息等)。相反,当计算设备118没有终止该消息时,它不会将其自己的证书附加到该消息。在没有将其证书附加到消息中的情况下,计算设备116和118以及API网关114被配置为利用结合接收到的消息本身提供的证明来校验消息的源计算设备(例如,通过MTLS等)。
此外,计算设备116被配置为解封消息的有效载荷,由此消息在计算设备116处终止,并且基于有效载荷生成消息的值。该值可以以任何数量的方式生成,并且可以基于有效载荷的任何方面。例如,当除以2(即,0或1)时,该值可以简单地包括PAN的余数或令牌。计算设备116然后被配置为确定消息的负载平衡路由,在图1的上下文中,例如是计算设备116(当值是0时)或是计算设备118(当值是1时)。当该值为0时,在该示例中,计算设备116被配置为重新包装消息并将其发送到API网关114。相反,当该值为1时,计算设备116被配置为重新包装消息并将其发送到计算设备118。应该理解,计算设备118被类似地配置成针对从内部客户端120接收的消息提供负载平衡。
接下来,API网关114被配置为当消息在计算设备116/118处终止时基于其中的本地储存库124(或LDAP 126)或者当消息没有在计算设备116/118处终止时基于中间计算设备122初始验证计算设备116/118。例如,在它们之间的通信中,当发送MTLS消息时,在终止来自中间计算设备122的消息之后,计算设备116/118被配置为将其证书传递给API网关114(作为相互认证的一部分)。API网关114进而被配置为访问存储在本地储存库124上或LDAP126中的验证变量,验证变量包括诸如经认证的设备名称(DN)的数据,用于识别可允许的计算设备。将验证变量与从计算设备116/118传递的证书中的数据(例如,request.authenticatedDN等)(或者可选地,通过计算设备(例如,计算设备116和118)附加到消息的数据)进行比较。如果比较成功,则计算设备被认证。在一些实施例中,API网关114可以将认证的设备名称分配给在整个交互中维持计算设备的认证状态的上下文变量(例如mc_systemID,mc_authenticatedDN等)。相反,在消息未在计算设备116/118处终止的情况下,API网关114被配置为基于其中的本地储存库124(或全局访问管理器127和/或LDAP126)来验证中间计算设备122。如果认证失败,则API网关114可以通过停止验证过程并提供解释认证失败的原因的消息来处理失败。
接着,API网关114被配置为打开消息的有效载荷并且通过使用作为客户端证书的附加对象来验证从其发送消息的客户端。为此,API网关114被配置为经由全局访问管理器127调用LDAP计算设备126(即,本地储存库124不包括用于向支付网络106验证每个客户端的内容)。当每一个被验证时,API网关114被配置为随后生成内部安全令牌,该内部安全令牌被转换为由(一个或多个)后端服务器112接受的安全令牌,之后将消息(包括安全令牌)发送到(一个或多个)后端服务器112,由此根据需要调用消息所针对的服务。
图3示出了用于在支付网络106内,在客户端级别并且进一步在计算设备级别上认证消息的示例性方法。示例性方法300被描述为在系统100中实现,进一步参考图1中所示的API网关114和计算设备116、118和122。例如,在该示例性实施例中,在图3中用虚线框包围的操作包括在API网关114中和/或由API网关114执行。然而,在其他实施例中,方法300可以在系统100的一个或多个其他实体或部分和/或支付网络106的部分中实现。并且,正如本文的方法不应被理解为限于示例性系统100或示例性计算设备200一样,此处的系统和计算设备不应被理解为限于示例性方法300。
参照由商家MPI发送并在中间计算设备122处接收的3D安全消息来描述方法300,如图1中的130所示。应当理解,可以从一个或多个其他外部实体接收消息,如图1或其他图所示,并且该消息可能与支付网络106的任何方面有关,但通常会被提供来通过一个或多个API访问由(一个或多个)后端服务器112提供的一个或多个服务,如上文所描述和/或陈述的。此外,可以在计算设备118处例如从虚线框120所指示的支付网络106内部或外部的一个或多个实体(例如,内部客户端、外部客户端等)接收消息,以通过一个或多个API再次访问一个或多个由(一个或多个)后端服务器112提供的服务。
参照图3,在302处,在计算设备122处从外部客户端,具体地在该示例中为商家102(和/或收单方104),经由MPI接收消息(例如,TLS消息等)。如上所述,MPI消息被提供用于根据3D安全协议等认证与支付账户交易相关的消费者。该MPI消息在计算设备122处经由网络110被接收(如在图1中130所指示的)。在该示例中,网络110是HTTP型网络,使得接收到的消息包括HTTP消息。然而,应该理解,在其他示例中可以使用不同类型的网络,由此消息可以是不同类型的或者根据不同的协议来提供。而且,从客户端接收的消息包括用于外部客户端的客户端证书,即商家MPI,特别是TLS证书。
一旦接收到该消息,中间计算设备122单独地或结合支付网络106内的一个或多个其他服务和/或计算设备来验证与给定消息相关联的客户端证书(作为启用从MPI或其他计算设备发送的消息传递的前奏来接收)。验证基于支付网络106内部或支付网络106外部的一个或多个检查。例如,中间计算设备122可以被配置为基于由专用认证机构(CA)签署的消息(例如,专用于MPI消息传递等)和/或基于消息中包括的签名或证书来验证消息,由此中间计算设备122排除消息,例如,当未由多个已知CA中的一个签署时。如果客户端被验证,则在304处,中间计算设备122将客户端证书(再次作为启用从MPI或其他计算设备发送的消息传递的前奏来接收)作为对象附加到消息,具体地,在该实施例中,作为X509对象附加到消息。X509对象可以附加到HTTP头部或消息的其他地方。另外或者可选地,中间计算设备122可以将其证书附加到消息并且在306处将该消息经由计算设备116发送到API网关114。或者,不是将中间证书附加到消息,中间计算设备122的证书可以替代地由中间计算设备122提供以发起与后续计算设备(例如,计算设备116等)的通信。然后证书通常在与消息相关联的传输层安全协议(TLS)中可用。
计算设备116在接收到该消息时验证附加到该消息的客户端证书,并且在计算设备116不终止时用作直通。当消息在计算设备116处终止时,例如,为了进一步验证和/或负载平衡,计算设备116另外解包并重新包装有效载荷,由此计算设备116编译并发起消息(包括接收到的消息的头部(包括X509对象或客户端证书))到API网关114,由此计算设备的证书包括在到API网关114的MTLS的消息中(用于相互认证)。除了将消息路由到API网关114之外(或作为其替代),计算设备116可以将消息路由到计算设备118。具体地,例如,当计算设备116解包消息的有效载荷时,计算设备116可以基于负载平衡或其他路由规则来确定将消息路由到计算设备118而不是API网关114(如以上在系统100中所讨论的)。应该理解的是,除了负载平衡之外,计算设备116可以在将消息传递给该API网关114之前执行与进一步验证和/或校验消息有关的一个或多个附加操作,或者过滤从计算设备122接收的该消息。
应该理解,当多个计算设备介于中间计算设备122和/或计算设备116与API网关114之间时,每个计算设备可以对消息执行各种负载平衡、验证等操作,由此消息可以被解包、修改和重新包装等。在一个实施例中,例如,与每个中间计算设备相关联的证书可以被附加到消息的有效载荷。在不同的实施例中,只有客户证书可以被附加到消息(例如,作为X509对象或其他等)(从而允许其他计算设备依赖与安全通信相关联的证书)。在又一个实施例中,某些计算设备可以将它们的证书附加到消息的有效载荷,而其他的计算设备则可以不它们的证书附加到消息的有效载荷。
然后在方法300中,API网关114接收该消息,并且在308处,从计算设备116或中间计算设备122验证证书(当消息未在计算设备116处终止时)。具体而言,API网关114从与接收消息(即,TLS消息)相关联的TLS中提取计算设备116或中间计算设备122的证书,然后依靠其本地储存库124(或全局访问管理器127和/或LDAP 126,如图3中虚线所示)中的证书验证数据以验证证书,从而确认它是允许API网关114与之通信的已识别计算设备(基于证书)。验证可以包括仅仅将证书中包括的特异名称与本地储存库124(或全局访问管理器127和/或LDAP126)中的已识别特异名称的列表进行比较。更经常地,API网关114通过执行计算设备116或中间计算设备122和API网关114之间的握手来执行对消息的完全验证(通过TLS信道接收),以验证来自计算设备116的认证机构信任链。一旦握手成功,消息就到达网关114,如上所述。API网关114将代表计算设备116的来自传入消息的客户端证书的特异名称(DN)与存储在本地储存库124(或LDAP 126)中的针对API网关114先前授权的所有计算设备的预定DN值的列表进行比较。如果找到匹配,则匹配的消息被成功验证。以这种方式,关于计算设备116的证书的消息验证在本地对API网关114执行,而不需要与单独的证书授权机构(诸如例如利用LDAP计算设备126的全局访问管理器127)进行通信。
如果验证显示该消息并非来自于已识别计算设备,则API网关114终止该消息,和/或启动该消息的一个或多个安全评论等。
相反,如果消息被验证到计算设备116,则API网关114在310处从消息提取对象,并且具体地在该示例中提取X509对象。然后,在312处,API网关114针对提供消息的客户端,即本示例中的商家MPI,执行对象验证(即客户端证书)。如图3所示,客户端证书的验证在该示例性实施例中要求API网关114访问全局访问管理器127的数据储存库(例如,LDAP数据库126等),其中存储了客户端的凭证(例如在存储器204等中)。基于此访问,API网关114然后在312处根据已知技术执行证书的验证。
在大多数情况下,如果消息无效或未验证,消息将被拒绝。然而,在该示例性实施例中,如果由于客户端或商家MPI 102未知而导致消息无效或未被验证,则在314处,API网关114调用后端服务器112中的(一个或多个)后端服务以提供新客户端,新客户端包括企业服务总线(ESB)。一般情况下,当证书或商家MPI 102对于支付网络106而言是未知的或是新的时候,API网关114调用后端服务,后端服务又转而注册客户端或商家MPI。然后从(一个或多个)后端服务器112向全局访问管理器127提供商家MPI的注册,从而为商家MPI创建客户端标识符。然后将客户端标识符提供给API网关114,API网关114转而如下所述地生成该消息的令牌。
相反,如果消息被验证,则API网关114促使为消息和/或客户端生成安全令牌。具体地,在316处,API网关114生成内部安全令牌。在该示例中,内部安全令牌包括特定于客户端的SAML(安全断言标记语言)令牌。在318处,API网关114然后调用SSCD 128。作为响应,如图3所示,SSCD 128在320处将内部安全令牌转换成可由支付网络106的其他部分识别的安全令牌,支付网络106的其他部分包括(一个或多个)后端服务器112和由其提供的服务。在转换之后,在该示例中也是SAML令牌的安全令牌被回复到API网关114,并随后在322处连同消息一起被发送到(一个或多个)后端服务器112。作为响应,(一个或多个)后端服务器112和/或交易数据的提供者或其他服务被允许以促进附加消息,如所请求的特定服务所要求的。在该示例性实施例中,响应于MPI消息,后端服务器112中的目录服务校验支付账户的注册状态,由此用于交易的3D安全协议可以继续。
除了中间计算设备122和计算设备116之外,如上所述,消息可以源自各种其他源,包括内部客户端120。在这种情况下,在计算设备118处接收消息(如参照步骤304所述),该消息进行将客户端证书作为对象(例如,X509对象等)附加到消息(并且进一步附加其自己的证书到消息),并将消息一起传递给API网关114,如上所述。API网关114然后执行与用于消息的步骤308-318和322一致的操作。
以上述方式,API网关114在客户端级别并进一步在计算设备级别(依赖本地储存库)提供对消息的双重级别的认证,以确保从已识别计算设备接收消息。因此,在允许消息在支付网络106内传递到达后端服务器和/或后端服务之前,在两个级别上验证从内部或外部客户端接收到的作为API消息的消息。在各种示例性实施例中,支付网络106的消息,特别是API消息的安全性经受增强的安全性,由此进一步保护至支付网络106、来自支付网络106和/或通过支付网络106的消息中包含的机密和/或敏感信息免受未经授权的访问。此外,这里描述的负载均衡(例如,基于消息有效载荷的内容而不是与消息相关联的令牌和/或cookie等)可以用于通过一致的计算设备确保和/或促进消息的处理,因此有助于减少延迟问题和/或改善对中继攻击的响应。
再次且如前所述,应该认识到,在一些实施例中,本文描述的功能可以在存储在计算机可读介质上并且可由一个或多个处理器执行的计算机可执行指令中描述。计算机可读介质是非暂时性计算机可读存储介质。作为示例而非限制,这样的计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储装置、磁盘存储装置或其他磁存储设备,或可用于以指令或数据结构的形式携带或存储期望的程序代码并且可以由计算机访问的任何其他介质。上述的组合也应该包括在计算机可读介质的范围内。
还应该理解,本公开的一个或多个方面在被配置为执行本文描述的功能、方法和/或过程时将通用计算设备转换成专用计算设备。
如基于前述说明书将理解的,本公开的上述实施例可以使用包括计算机软件、固件、硬件或其任何组合或子集的计算机编程或工程技术来实现,其中技术效果可以通过执行以下中的至少一个来实现:(a)从客户端接收API消息,所述API消息包括客户端证书;(b)通过计算设备将客户证书作为对象附加到API消息中;(c)通过计算设备将附加的API消息发送到API网关,所述API网关与多个已识别计算设备相关联;(d)由所述API网关基于将所述计算设备识别为已识别计算设备中的一个的证书来验证所述计算设备;(e)由所述API网关基于附加到所述API消息的所述客户端证书来验证所述客户端;以及(f)当计算设备和客户端被验证时,使得指示客户端的安全令牌被生成,由此安全令牌指示客户端并且允许来自客户端的API消息要被递送给一个或多个后端服务。
据此,提供了示例性实施例以使得本公开将是彻底的,并且将范围充分地传达给本领域技术人员。阐述了许多具体细节,诸如具体组件、设备和方法的示例,以提供对本公开的实施例的全面理解。对于本领域技术人员来说显而易见的是,不需要采用具体细节,示例实施例可以以许多不同的形式来体现,并且都不应该被解释为限制本公开的范围。在一些示例实施例中,没有详细描述公知的过程、公知的设备结构和公知的技术。
这里使用的术语仅用于描述特定示例性实施例的目的,而不意图是限制性的。除非上下文另有明确指示,否则单数形式“一”、“一个”和“该”可以意图包括复数形式。术语“包括”、“包含”和“具有”是包含性的,并且因此指定所述特征、整体、步骤、操作、元件和/或组件的存在,但不排除存在或增加一个或多个其他特征、整体、步骤、操作、元件、组件和/或它们的组合。除非特别标识为执行的顺序,否则本文描述的方法步骤、过程和操作不应被解释为必须要求它们以所讨论或说明的特定顺序执行。也应该理解可以采用附加的或替代的步骤。
当元件或层被称为在另一元件或层“上”、“接合到”另一元件或层,“连接到”另一元件或层、“耦合到”另一元件或层、“与另一元件或层相关联”或“包括有”另一元件或层时,它可以直接位于另一元件或层上、接合另一元件或层、连接到或耦合到另一元件或层或与另一元件或层相关联,或者可以存在中间元件或层。如本文所使用的,术语“和/或”包括一个或多个相关所列项目的任何一个和所有组合。
示例性实施例的前述描述已经被提供用于说明和描述的目的。其目的不是穷举或限制披露的内容。即使没有具体示出或描述,特定实施例的单独元件或特征通常不限于该特定实施例,而是在适用的情况下可互换并且可用于选定实施例中。在许多方面也可能有所不同。这样的变化不被认为是背离本公开,并且所有这样的修改旨在被包括在本公开的范围内。
Claims (20)
1.一种用于向网络提供对应用程序编程接口(API)消息的认证的计算机实现的方法,所述方法包括:
从客户端接收API消息,所述API消息包括客户端证书;
由计算设备将所述客户端证书作为对象附加到所述API消息;
由所述计算设备将附加的API消息发送到API网关,所述API网关与多个已识别计算设备相关联;
由所述API网关基于将所述计算设备识别为已识别计算设备中的一个的证书,验证所述计算设备;
由所述API网关基于附加到所述API消息的所述客户端证书,验证所述客户端;以及
当所述计算设备和所述客户端被验证时,使得指示客户端的安全令牌被生成,由此所述安全令牌指示所述客户端并且允许来自所述客户端的API消息被递送到一个或多个后端服务。
2.如权利要求1所述的方法,其中,验证所述计算设备包括验证所述识别所述计算设备的证书的特异名称与所述已识别计算设备中的一个一致。
3.如权利要求1所述的方法,其中,使所述安全令牌被生成包括:
当所述计算设备被验证并且所述客户端被验证时,生成内部安全令牌;
使安全服务计算设备将所述内部安全令牌转换为所述安全令牌;以及
将包括所述安全令牌的API消息发送到由所述API消息指示的所述一个或多个后端服务。
4.如权利要求3所述的方法,其中,所述内部安全令牌和所述安全令牌中的至少一个包括安全断言标记语言(SAML)令牌。
5.如权利要求1所述的方法,还包括在将所述客户端证书作为所述对象附加到所述API消息之前,由所述计算设备基于所述客户端证书经由全局访问管理器来验证所述客户端。
6.如权利要求1所述的方法,其中,所述对象包括X509对象;以及
其中,将所述客户端证书附加到所述API消息包括将所述X509对象附加到API消息的头部。
7.如权利要求1所述的方法,其中,所述API消息包括HTTP请求;以及
其中,将所述客户端证书附加到所述API消息包括将所述客户端证书作为X509对象附加到HTTP请求的头部。
8.如权利要求1所述的方法,其中,所述客户端包括与3D安全协议相关联的商家插件(MPI);并且
其中,所述API消息包括认证请求。
9.如权利要求1所述的方法,还包括当所述计算设备未被验证时终止所述API消息。
10.一种用于认证消息的支付网络,所述支付网络包括:
中间计算设备;以及
应用程序编程接口(API)网关,所述应用程序编程接口网关耦合到所述中间计算设备并且包括已识别计算设备的本地储存库;所述API网关通过可执行指令被配置为:
与所述计算设备的证书相关联地从计算设备接收消息,所述消息包括证书对象;
基于与所述中间计算设备和所述计算设备中的至少一个相关联的证书,来将所述中间计算设备和所述计算设备中的所述至少一个验证为已识别计算设备中的一个;
从所述消息中提取所述证书对象并基于所述证书对象验证客户端;以及
当所述中间计算设备被验证时,如所述消息中所指示的,将指示所述客户端的安全令牌发送到所述支付网络的服务提供者。
11.如权利要求10所述的支付网络,还包括全局访问管理器的数据储存库;并且
其中,所述API网关包括本地储存库并且被配置为:
调用所述数据储存库;
基于所述数据储存库、基于所述证书对象验证所述客户端;以及
基于所述本地储存库和所述数据储存库中的至少一个来验证所述中间计算设备和所述计算设备中的所述至少一个。
12.如权利要求11所述的支付网络,其中,所述中间计算设备被配置为从所述客户端接收所述消息,所述消息包括客户端证书;基于所述客户端证书来验证所述客户端计算设备;并将所述客户端证书作为证书对象附加到所述消息的头部。
13.如权利要求12所述的支付网络,其中,所述API网关被配置为在验证所述中间计算设备之前,从与所述消息相关联的传输层安全协议提取与所述中间计算设备相关联的证书。
14.如权利要求11所述的支付网络,还包括耦合到所述API网关的安全服务计算设备;以及
其中,所述API网关被配置为当所述中间计算设备和所述客户端被验证时生成内部安全令牌,并且将所述内部安全令牌发送到所述安全服务计算设备;以及
其中,所述安全服务计算设备被配置为将所述内部安全令牌转换成所述安全令牌并且将所述安全令牌回复到所述API网关,由此所述安全令牌被接受为由一个或多个后端服务器进行的验证。
15.如权利要求10所述的支付网络,其中,所述API网关进一步被配置为:在验证所述计算设备之前,从与所述消息相关联的传输层安全协议提取与所述计算设备相关联的证书。
16.如权利要求15所述的支付网络,其中,所述本地储存库包括每个计算设备的特异名称的列表,所述API网关被授权从所述每个计算设备接收消息;并且
其中,验证所述计算设备包括验证与所述计算设备相关联的证书的所述特异名称。
17.如权利要求10所述的支付网络,其中,所述API网关被配置为基于所述中间证书和所述本地储存库中包括的特异名称,内部验证所述中间计算设备。
18.一种非暂时性计算机可读存储介质,包括用于向支付网络提供对应用程序编程接口(API)消息的认证的可执行指令,所述可执行指令在由至少一个处理器执行时使得所述至少一个处理器:
接收来自计算设备的附加API消息,所述附加API消息包括与客户端相关联的客户端证书;
基于所述计算设备的证书来执行所述计算设备的验证;
通过独立于所述储存库的全局访问管理器基于所述客户端证书执行所述客户端的验证;以及
当所述计算设备被验证时,使得指示所述客户端的安全令牌被生成,由此所述安全令牌指示所述客户端并且允许来自所述客户端的API消息被递送到用于所述支付网络的一个或多个后端服务。
19.如权利要求18所述的非暂时性计算机可读存储介质,其中,所述客户端证书包括附加到附加API消息的头部的X509对象。
20.如权利要求18所述的非暂时性计算机可读存储介质,其中,所述可执行指令在由所述至少一个处理器执行时,使所述至少一个处理器通过验证与所述证书相关联的特异名称与已识别计算设备中的一个一致,来执行所述计算设备的验证。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/707,726 | 2015-11-16 | ||
US15/707,726 US10673839B2 (en) | 2015-11-16 | 2017-09-18 | Systems and methods for authenticating network messages |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109525394A true CN109525394A (zh) | 2019-03-26 |
CN109525394B CN109525394B (zh) | 2022-03-15 |
Family
ID=65769781
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810661056.XA Active CN109525394B (zh) | 2017-09-18 | 2018-06-25 | 用于认证网络消息的系统和方法 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN109525394B (zh) |
SG (1) | SG10201803964RA (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112994894A (zh) * | 2021-02-26 | 2021-06-18 | 中国工商银行股份有限公司 | 基于网关的单线程请求处理方法和信息验证agent |
CN114363896A (zh) * | 2020-09-29 | 2022-04-15 | 辉达公司 | 使用建立的通信信道验证受信通信 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120179913A1 (en) * | 2011-01-07 | 2012-07-12 | Stephen Christopher Kirk | Method and system for propagating a client identity |
CN105160233A (zh) * | 2015-09-07 | 2015-12-16 | 北京祥云智信科技有限公司 | 一种读取用户数字证书的方法、装置及系统 |
CN105553654A (zh) * | 2015-12-31 | 2016-05-04 | 广东信鉴信息科技有限公司 | 密钥信息查询处理方法和装置、密钥信息管理系统 |
US9462044B1 (en) * | 2013-11-25 | 2016-10-04 | Ca, Inc. | Secure user, device, application registration protocol |
-
2018
- 2018-05-10 SG SG10201803964RA patent/SG10201803964RA/en unknown
- 2018-06-25 CN CN201810661056.XA patent/CN109525394B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120179913A1 (en) * | 2011-01-07 | 2012-07-12 | Stephen Christopher Kirk | Method and system for propagating a client identity |
US9462044B1 (en) * | 2013-11-25 | 2016-10-04 | Ca, Inc. | Secure user, device, application registration protocol |
CN105160233A (zh) * | 2015-09-07 | 2015-12-16 | 北京祥云智信科技有限公司 | 一种读取用户数字证书的方法、装置及系统 |
CN105553654A (zh) * | 2015-12-31 | 2016-05-04 | 广东信鉴信息科技有限公司 | 密钥信息查询处理方法和装置、密钥信息管理系统 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114363896A (zh) * | 2020-09-29 | 2022-04-15 | 辉达公司 | 使用建立的通信信道验证受信通信 |
CN112994894A (zh) * | 2021-02-26 | 2021-06-18 | 中国工商银行股份有限公司 | 基于网关的单线程请求处理方法和信息验证agent |
CN112994894B (zh) * | 2021-02-26 | 2023-12-08 | 中国工商银行股份有限公司 | 基于网关的单线程请求处理方法和信息验证agent |
Also Published As
Publication number | Publication date |
---|---|
CN109525394B (zh) | 2022-03-15 |
SG10201803964RA (en) | 2019-04-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10846663B2 (en) | Systems and methods for securing cryptocurrency purchases | |
US20200336315A1 (en) | Validation cryptogram for transaction | |
US9978094B2 (en) | Tokenization revocation list | |
AU2018203506B2 (en) | Systems and methods for authenticating network messages | |
US6327578B1 (en) | Four-party credit/debit payment protocol | |
JP6031524B2 (ja) | 安全に補充可能な電子ウォレット | |
CN109328445A (zh) | 唯一令牌认证验证值 | |
US10673839B2 (en) | Systems and methods for authenticating network messages | |
US11816666B2 (en) | Secure payment processing | |
KR20190043117A (ko) | 블록체인 기반의 결제 방법 및 이를 이용한 지급 결제 서버 | |
CN109525394A (zh) | 用于认证网络消息的系统和方法 | |
KR20190084923A (ko) | 블록체인 기반의 결제 방법 및 이를 이용한 지급 결제 서버 | |
EP4278316A1 (en) | Token-based off-chain interaction authorization | |
US20240135339A1 (en) | Secure and compliant multi-cryptocurrency payment gateway | |
US20230298009A1 (en) | Rapid cryptocurrency transaction processing | |
KR101596434B1 (ko) | 결제정보 분리를 이용한 온라인 전자금융거래 인증방법 | |
US11812260B2 (en) | Secure offline mobile interactions | |
Carbonell et al. | Security analysis of a new multi-party payment protocol with intermediary service. | |
EP3690782A1 (en) | Secure and confidential payment | |
Turcu | Security in Electronic Payment Systems | |
KR20020089729A (ko) | 유·무선 복합 전자 결제 방법 및 시스템 | |
Herzberg et al. | Layered Architecture for Secure E-Commerce Applications. | |
CN112559990A (zh) | 一种基于区块链技术的房产上链和价值流通方法及系统 | |
Kim et al. | A secure credit card transaction method based on Kerberos | |
Faraj | Design and Implementation of SET-Enabled E-Commerce System |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |