Patent Application
20120096546
This application is based on Ser. No. 61/346,243, filed May 19, 2010.
This application includes subject matter protected by copyright, and all rights are reserved.
1. Technical Field
This disclosure relates generally to transaction processing at a server in a distributed network.
2. Brief Description of the Related Art
Distributed computer systems are well-known in the prior art. One such distributed computer system is a “content delivery network” or “CDN” that is operated and managed by a service provider. The service provider typically provides the content delivery service on behalf of third parties. A “distributed system” of this type typically refers to a collection of autonomous computers linked by a network or networks, together with the software, systems, protocols and techniques designed to facilitate various services, such as content delivery or the support of outsourced site infrastructure. Typically, “content delivery” means the storage, caching, or transmission of content, streaming media and applications on behalf of content providers, including ancillary technologies used therewith including, without limitation, DNS query handling, provisioning, data monitoring and reporting, content targeting, personalization, and business intelligence.
It is desired to provide CDN customers with one or more “edge” services that can take advantage of the scalability, availability and reliability of a distributed network of this type.
Several enhanced “edge services” are provided by an edge server message processing method and apparatus, as described herein.
According to this disclosure, a CDN edge server process receives an HTTP message, takes a given action with respect to that message, and then forwards a modified version of the message to a target server, typically a server associated with a CDN customer. The edge server process may include an associated intermediate processing agent (IPA) or a sub-processing thread to facilitate the given action. The edge server process receives configuration data, referred to as metadata, to control the processing.
In an illustrative embodiment, the message is an HTTP POST, and the given action comprises the following: (i) recognizing the POST, (ii) removing given data from the POST, (iii) issuing an intermediate (or subordinate) request to another process (e.g., a third party server), passing the given data removed from the POST to the process, (iv) receiving a response to the intermediate request, (v) incorporating data received from or associated with the response into a new HTTP message, and (vi) forwarding the new HTTP message onto the target server. In this manner, the given data in the POST may be protected as the HTTP message “passes through” the edge server on its way from the client to a target server, such as a merchant.
This technique has the effect of protecting or enhancing data within an HTTP POST message body as that POST traverses the edge server. In one embodiment, the edge server process uses this “out of band” processing to receive (from the third party “process”) a handle or “nonce” that it then positions in the HTTP POST message body in lieu of the data that is desired to be protected (from being passed on to the merchant web application). This substitution has the effect of obfuscating the data within the POST message body that is desired to be “protected.” In another embodiment, the data within the HTTP POST message body is not necessarily removed but rather is “enhanced,” for example, by examining the existing data and adding a derivative value, such as a fraud risk score based on the data, the result of a lookup of a value in the POST body against a database of part numbers to facilitate cross-vendor ordering, or the like.
The described technique may operate with other HTTP message types.
The foregoing has outlined some of the more pertinent features of the invention. These features should be construed to be merely illustrative. Many other beneficial results can be attained by applying the disclosed invention in a different manner or by modifying the invention as will be described.
In a known system, such as shown in
As illustrated in
A CDN edge server is configured to provide one or more extended content delivery features, preferably on a domain-specific, customer-specific basis, preferably using configuration files that are distributed to the edge servers using a configuration system. A given configuration file preferably is XML-based and includes a set of content handling rules and directives that facilitate one or more advanced content handling features. The configuration file may be delivered to the CDN edge server via the data transport mechanism. U.S. Pat. No. 7,111,057 illustrates a useful infrastructure for delivering and managing edge server content control information, and this and other edge server control information can be provisioned by the CDN service provider itself, or (via an extranet or the like) the content provider customer who operates the origin server.
The CDN may include a storage subsystem, such as described in U.S. Pat. No. 7,472,178, the disclosure of which is incorporated herein by reference. The CDN may operate a server cache hierarchy to provide intermediate caching of customer content; one such cache hierarchy subsystem is described in U.S. Pat. No. 7,376,716, the disclosure of which is incorporated herein by reference. The CDN may provide secure content delivery among a client browser, edge server and customer origin server in the manner described in U.S. Publication No. 20040093419. Secure content delivery as described therein enforces SSL-based links between the client and the edge server process, on the one hand, and between the edge server process and an origin server process, on the other hand. This enables an SSL-protected web page and/or components thereof to be delivered via the edge server.
With the above as background, the subject matter of this disclosure is now described.
According to an aspect of this disclosure, a CDN edge server process receives an HTTP message, takes a given action with respect to that message, and then forwards a modified version of the message to a target server, typically a server associated with a CDN customer. The process may include an associated intermediate processing agent (IPA) or a sub-processing thread to facilitate the given action, but this is not strictly required. Preferably, the process receives configuration data, referred to as metadata, to control the processing of the HTTP message.
In one embodiment, the message is an HTTP POST, and the given action comprises the following: (i) recognizing the POST, (ii) removing given data from the POST, (iii) issuing an intermediate (or subordinate) request to another process (e.g., a third party server), passing the given data removed from the POST to the process, (iv) receiving a response to the intermediate request, (v) incorporating data received from or associated with the response into a new HTTP message, and (vi) forwarding the new HTTP message onto the target server. In this manner, the given data in the POST may be protected as the HTTP message “passes through” the edge server on its way from the client to the target (merchant) server.
In this embodiment, the technique has the effect of obfuscating or obscuring data within an HTTP POST message body as that POST traverses the edge server. In particular, the edge server process uses this “out of band” processing to receive (from the third party “process”) a handle or “nonce” that it then positions in the HTTP POST message body in lieu of the data that is desired to be protected (from being passed on to the merchant web application).
An application of this approach is an edge-based “tokenization” where the HTTP POST is generated from a SSL-protected web page (e.g., a merchant checkout page from an e-commerce web site that is delivered via the CDN), and the intermediate request passes a credit card (CC) number to a third party payment gateway. In this case, the data received form the intermediate request is a token, which token is then placed in the HTTP request that is passed onto the merchant origin server (and, in particular, a web order management application executing thereon).
The HTTP POST message processing technique may also be used to “enhance” the data in the message as opposed to just protecting (obscuring) it. In this approach, the data in the POST message is examined. Based at least in part on that examination, the data is “enhanced,” perhaps by including a value that is derived in whole or in part from the data in the POST. As one example, an edge-based “fraud” detection service may be implemented across the edge servers. A representative edge server would then perform the following: HTTP POST scanning, IPA-based forward request, e.g., to a fraud platform “process,” receiving a response (e.g., a risk score), and (risk score) injection into the original POST that is then passed on to the target (merchant) server (application). This is an example of “enhancing” the HTTP POST data and, in particular, by examining the existing data (in the POST) and adding a derivative value.
The fraud score embodiment is just a representative example of the “enhancement” technique. Another example would be a cross-vendor ordering service, in which case the derived value may be based on a lookup of the value in the POST body against an external database of part numbers, or the like. The particular applications for the approach thus are quite varied.
Where the edge server process (or IPA if used) communicates with an external process, the communications may be over SSL, via a Web service, or the like.
Another alternative is an edge-based encryption wherein a given field in the HTTP message is encrypted (or, if already encrypted, decrypted) with a key as the HTTP message passes through the edge server.
Preferably, metadata is used to configure the edge server process to provide one or more of these edge service functions. The above-described processing may take place over communication links using SSL (or its equivalent).
The HTTP message being processed is not necessarily limited to a POST, as the above-described techniques may be implemented on other HTTP message formats, such as GET, PUT, or the like.
An illustrative example of one of these services, edge-based tokenization, is now described. This example should not be taken by way of limitation.
The following provides additional technique details of a representative implementation of the edge tokenization service. As noted above, this service is merely representative.
In general, the tokenization module (operation) replaces a card number in an eCommerce transaction with an anonymous “token” supplied by a third party payment gateway. This reduces risk of exposure of card numbers for our merchant customers and may help take the merchant's web site out of PCI scope.
In general, tokenization is the capability for a CDN edge server to:
As used herein, “card number” means any PCI sensitive data that can be replaced by a token, for example a credit or debit card number, a bank account number, and so forth. The token and the card number it represents are stored securely in a data vault managed by the payment gateway provider.
A third party payment gateway need not always be used. The “token” generation (or, more generally, the processing being carried out by the target of the intermediate or subordinate request) may be performed by the CDN in appropriate circumstances.
The tokenizer uses a POST request parser, an Intermediate Processing Agent (IPA), and adds ability for IPA to POST (preferably over SSL), client POST body modification, error handling, logging and reporting.
Note that the module accesses personally identifiable information (consumer name, card number, home address, and so forth). Preferably, the edge server process does not write any PII to disk (for logging, billing or other purposes).
The module preferably provides customer controls over the authenticators used to access the payment gateway. The bulk of the metadata configuration management in this version of the module is customized via metadata. In an alternative embodiment, template-based configuration management may be provided for customer self-service.
The sections that follow present a high level design for the components and processes that implement edge tokenization.
Edge-based tokenization integration and configuration management (provisioning) preferably is done through a customer (secure extranet portal) configuration application. As described below, metadata provides an interface to extract cardholder data from the POST body, generate the intermediate request to the payment gateway, and modify the forward POST transaction. Use of that metadata plus a tokenization tag constitutes activation of this module.
The tokenization request to the payment gateway depends on the API available from the gateway provider. At a minimum, the solution supports an HTTPS POST request with a text reply of key=value pairs or an XML document reply. The gateway interface may be password protected using HTTP Basic Auth credentials in the HTTP headers or as a key=value in the POST body. If the gateway will allow it, the edge machine may be securely authenticated to the payment gateway. This avoids the merchant having to share their payment gateway credentials with the CDN service provider.
The fields to extract from the POST body depend on the merchant's shopping card or order processing software. The syntax and semantics are managed through metadata in the merchant's metadata configuration. Example metadata is set forth below.
The payment gateway requires merchant identification and authentication, often a username and password for the merchant. These credentials to the merchant's gateway account are security sensitive and preferably are not stored cleartext in metadata. Instead, the edge server process preferably retrieves the credentials via a key management infrastructure to prevent them being available in the clear.
Merchant authenticators (and any other secrets required) preferably are managed via a portal configuration management interface to prevent customers having to transmit secrets to the CDN employees via email or other mechanisms.
Any payment transaction configured for edge tokenization would be authorized to use the merchant's credentials to access the payment gateway.
Edge Tokenization leverages an intermediate processing agent (IPA) feature within the edge process to interact with the payment gateway API. The construction of the POST to the payment gateway is flexible enough to allow integration of new payment processors without requiring a code change.
The following provides a high level design of the edge server features.
The primary edge server steps in the processing of edge-based tokenization are set forth below.
The interface to tokenization may be through profile functionality. A profile typically represents an end user, referring to their PII (name, address, phone, card number, expiration, etc.) with an anonymous token or profile identifier. Profile functionality may be accessed via a SOAP request, by a web service using binary API, or through an HTTPS POST interface with name=value attributes in the request and response.
In the case of new users visiting a customer web site, the edge server process will request a new token be created. If the user has already visited the site they should have a profile already. In this case the POST from the merchant's form should contain only the profile identifier, not the full card number. In this case we would not call the tokenization API, just pass the POST through immediately.
If the call through the edge server process does create a profile for the user, the merchant should extract the profile from the request and store it in their database for use next time the user returns.
When IPA is used, an IPA request is converted to a POST by specifying the “post-body” tag explained above, which also adds a “Content-Length” header. The “post-body” can contain arguments that are expanded. These arguments must be appropriately encoded, either as url-encoded, plain text, or html-entity-encoded, depending on the type of POST body (xml, name-value pairs). A “Content-Type” header is added using a <edgeservices:modify-outgoing-request.add-header> tag in the <match:processing-agent-request> tag, specifying “application/x-www-form-urlencoded” or another appropriate value.
To allow a POST in an IPA, <security:allow-post>on</security:allow-post> is needed in the <match:processing-agent-request> tag.
The upstream POST preferably is modified with the variables extracted from the IPA response. The tags <edgeservices:add/remove/modify-outgoing-request.remove-post-argument> allow modification of the POST body. To extract values from the incoming POST request, an <edgeservices:inspect-request-body.status> tag is activated and an appropriate <edgeservices:inspect-request-body.limit> is specified. A <match:regex> tag allows the process to extract values from the POST body. For the incoming POST request, a selector such as “ARGS_POST:fieldname” may be used, with regex=“.*” provides the field value in the desired format. To extract values from the IPA response, a regex selector called IPA_RESPONSE_BODY may be used. This selector specifically allows the access of the IPA response body. The IPA POST http status response is extracted using a selector “IPA_RESPONSE_STATUS”.
Interaction with Fraud Detection
As noted above, the HTTP POST message processing described above may be leveraged to create an edge-based fraud module to do device detection or identification prior to routing the request to the merchant website. This reduces integration demands on a merchant site by obviating a separate call out to the fraud platform (from the merchant site).
The CDN customer (the merchant) would still have to integrate a device id or risk score into its order management system or process. One option is to modify the software to accept or reject transactions on the basis of real-time risk scoring. Another is to provide the vendor an offline risk score that the merchant can review during their order fulfillment process, declining to fill fraudulent transactions.
The edge services fraud interaction leverages POST scanning, IPA-based forward request to a fraud platform, and risk score injection into the original POST. There is no need to remove or replace an existing field, and perhaps no need to modify the POST—the risk score could be inserted as an HTTP header using existing capabilities.
The edge-based fraud detection may be carried out at the same time the tokenization occurs (i.e., within the same HTTP request processing). In such case, two (2) separate intermediate requests are carried out, one to the fraud engine (for the risk score) and one to the payment gateway (for the token).
This module relies on a third party payment gateway with secure data vault that associates tokens with the relevant cardholder data (card number, name, address, phone . . . ) and provides a secure interface to extract PII data given a token.
As previously described, the edge server process can invoke other payment processing API functions, for example request credit approval, in parallel with the tokenization request. Approval status added to the POST body saves the merchant having to initiate the request separately.
While the above describes a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary, as alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, or the like. References in the specification to a given embodiment indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic.
While the disclosed subject matter has been described in the context of a method or process, the subject disclosure also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including an optical disk, a CD-ROM, and a magnetic-optical disk, a read-only memory (ROM), a random access memory (RAM), a magnetic or optical card, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. While given components of the system have been described separately, one of ordinary skill will appreciate that some of the functions may be combined or shared in given instructions, program sequences, code portions, and the like.
As noted above, the described techniques may be implemented with respect to any HTTP request having a message body (including, without limitation, GET, PUT, other WebDAV types, and the like).
In general, the information returned to the edge server (from the IPA processing) is a function of the data extracted from the HTTP message. As described, a third party can associate (map) the extracted data with the information returned as needed dependent on the particular application.
| Number | Date | Country | |
|---|---|---|---|
| 61346243 | May 2010 | US |
