Bi-directional application programming interface to implement operational action functionality in one-way transfer system

Abstract

Examples of the present disclosure describe systems and methods for a bi-directional application programming interface (API) capable of implementing operational action functionality in a one-way transfer (OWT) system. In an example, a data request is received at a first computing environment of an OWT system, where the data request is associated with a first one-way data stream having a transaction identifier. A first set of policies associated with the first computing environment is applied to the data request, and the data request is communicated to a second computing environment of the OWT system. The second computing environment retrieves response data for the data request, wherein the response data is associated with a second one-way data stream having a transaction identifier. A second set of policies associated with the second computing environment is applied to the response data, and the response data is communicated to the first computing environment to complete the data request.

Description

BACKGROUND

[0001] One-way transfer systems facilitate one-way transfer of data across one or more data boundaries. Due to the one-way nature of data transfer, one-way transfer systems typically provide limited operational action functionality across data boundaries, as the sending side of the one-way transfer system typically cannot track data requests sent to the receiving side of the one-way transfer system, nor receive information from the receiving side of the one-way transfer system. As a result, gathering information related to the performance and maintenance of systems on the receiving side of a one-way transfer system, while ensuring the security and integrity of data transferred or stored by such systems, can be of great challenge.

[0002] It is with respect to these and other general observations that aspects disclosed herein were presented. While relative specific problems can be described, it should be understood that the examples should not be limited to addressing the specific problems identified in the background of the present disclosure or elsewhere. SUMMARY

[0003] Examples of the present disclosure describe systems and methods for implementing a bidirectional application programming interface (API) for operational action functionality in a one-way transfer (OWT) system. In examples, a data request from a requestor is received at a first computing environment of an OWT system, where the data request is associated with a first one-way data flow having a transaction identifier. A first set of policies associated with the first computing environment are applied to the data request, and the data request is transferred as part of the first one-way data flow to a second computing environment of the OWT system. Response data for the data request is retrieved by the second computing environment, where the response data is associated with a second one-way data flow having the transaction identifier. A second set of policies associated with the second computing environment are applied to the response data, and the response data is transferred as part of the second one-way data flow to the first computing environment of the OWT system. The response data is provided to the requestor to complete the data request.

[0004] This summary is provided to introduce selected concepts of the concepts that will be further described in the detailed description below. This summary does not necessarily identify key or essential BRIEF DESCRIPTION OF DRAWINGS

[0005] Examples are described with reference to the following figures.

[0006] Figure 1 FIGURE 1 illustrates an example system for implementing a bidirectional API capable of implementing operational action functionality in an OWT system.

[0007] Figure 2 FIGURE illustrates an example process flow for completing a data request using a bidirectional API that implements operational action functionality.

[0008] Figure 3 FIGURE illustrates an example method for transmitting and receiving data in an OWT system using a bidirectional API.

[0009] Figure 4 is a block diagram illustrating example physical components of a computing device with which aspects of the disclosure can be practiced.

[0010] Figure 5 is a simplified block diagram of an example distributed computing system for use in practicing aspects of the present disclosure. DETAILED DESCRIPTION

[0011] One-way transfer (OWT) systems facilitate one-way transfer of data across one or more data boundaries of the OWT system. An OWT system refers to a computing system in which one or more endpoints are data diodes configured to ensure that data packets can only be transferred through the computing system in one direction. In many cases, OWT systems are used to protect networks or endpoints from outbound data transmissions, malicious inbound data transmissions (e.g., viruses and malware), and cyber attacks. As one example, OWT systems facilitate data transfer between computing environments having the same or different security levels (e.g., high security or low security), where at least one of the computing environments is low trust relative to the other computing environment. For example, a first computing environment that is high trust relative to a device of the first computing environment and / or relative to devices of one or more other computing environments can receive data from a second computing environment that is considered low trust by the first computing environment.

[0012] In examples, a high-trust environment refers to a system or network in which devices, applications, and users are considered to be trustworthy, and security measures are deployed to establish and maintain that trust. In this type of environment, the involved devices and / or participants, such as devices, software, and users, are typically authenticated, authorized, and / or comply with established security policies and best practices. A high-trust environment typically has strict access controls, encryption, and monitoring to ensure that the trust is maintained and the risk of unauthorized access, data breaches, or other security incidents is minimized. Based on the security technologies implemented by a high-trust environment (e.g., unique encryption keys, secrets, or other cryptography techniques), devices within a high-trust environment can be authorized to access other devices or be accessed by other devices. For example, based on a high-trust environment (or its devices) being included in an allowed list (e.g., a list of approved devices and / or computing environments), communications transmitted by a high-trust environment can be considered trustworthy by other computing environments or devices. Alternatively, based on a password or credential provided with a communication, a communication transmitted by a high-trust environment can be considered trustworthy. In some examples, devices in a high-trust environment do not need to be authenticated to access other devices or be accessed by other devices. A high-trust environment generally does not expose the security technologies it implements to other computing environments, which can be considered low-trust or no-trust environments by the high-trust environment.

[0013] In contrast, a low-trust or no-trust environment refers to a system or network in which devices, applications, and / or users are not implicitly trusted or in which there is a high risk of unauthorized access or malicious activity. A low-trust or no-trust environment can have limited security measures, or no security measures, or can include or be connected to one or more external or unmanaged devices. Alternatively or additionally, a low-trust or no-trust environment refers to an environment in which devices are not considered safe or trustworthy by other devices within and / or outside of the low-trust or no-trust environment. Because the security technologies implemented by a high-trust environment are not exposed to a low-trust or no-trust environment, a low-trust or no-trust environment can not be able to access or communicate with a high-trust environment without performing various authorization and / or authentication steps that are not required to be performed by devices in a high-trust environment. In examples, an OWT system can encompass or include multiple computing environments separated by one or more boundaries between computing environments of different trust levels and / or security levels.

[0014] A data diode of an OWT system ensures one-way data packet transfer by implementing hardware and / or software components. In one example, the data diode includes a transmit-only network interface card (NIC). The transmit-only NIC transmits data to an endpoint but cannot receive data from the endpoint due to a physical break of receive pins on a network controller chip of the transmit-only NIC. The transmit-only NIC can also include firmware that sets a link state of the transmit-only NIC to always "active" (e.g., enabled and / or active state). In another example, the data diode implements a standard (e.g., commercial) NIC and a Y-splitter cable. The Y-splitter separates the data transmission signal such that a first cable of the Y-splitter is connected to a receiving device and a second cable of the Y-splitter is directed back to a transmitting device to establish a Layer 1 link state. In yet another example, the data diode implements one or more field programmable gate array (FPGA) devices to ensure one-way data flow.

[0015] Due to the inherent one-way nature of data transfer in an OWT system, the OWT system does not provide operational action functionality across data boundaries of the OWT system. As used herein, operational action functionality refers to the ability to transfer, interact, or manipulate data in a manner that provides a user with a synchronous experience. For example, a source endpoint submits a synchronous transmission of a first data stream corresponding to a data request to a destination endpoint, and the destination endpoint submits a corresponding synchronous transmission of a second data stream responsive to the data request to the source endpoint. In contrast, the OWT system transmits the data request from the source endpoint in a first computing environment (e.g., a low-trust environment) to the destination endpoint in a second computing environment (e.g., a high-trust environment). The source endpoint cannot track the data request that is transmitted to the second computing environment because the source endpoint has limited or no visibility into the second computing environment. When the data request is a synchronous request, the source endpoint cannot receive a response to the data request because the OWT system does not allow response data to be transmitted from the second computing environment to the first computing environment. Thus, the OWT system treats synchronous data requests as asynchronous data requests that do not provide a response. Without a collector (or collection device) in the second computing environment, information related to data, performance, and maintenance stored and transferred by the OWT system cannot be safely collected because the source endpoint cannot collect the response data from the destination endpoint. This presents a significant barrier to maintaining the OWT system and managing data transferred and stored by the OWT system for users outside of the second environment (e.g., support teams and administrators).

[0016] The present disclosure provides solutions to the above-described obstacles of securely collecting relevant information in an OWT system. Embodiments of the present disclosure describe systems and methods for a bidirectional application programming interface (API) that enables secure operation action functionality in an OWT system. In an example, a synchronous data request from a requestor is received by a first bidirectional mechanism in a first computing environment of an OWT system. The data request is associated with an asynchronous first unidirectional data flow having a data flow identifier that identifies the data request. In some examples, a transaction identifier is associated with a use case that describes a user goal or a particular scenario for the data request. For example, a first use case can be associated with requesting a first set or first type of data, and a second use case can be associated with requesting a second set or second type of data. The first bidirectional mechanism facilitates the transfer of the first unidirectional data flow through the first computing environment.

[0017] A first set of policies associated with the first computing environment is applied to the data request to ensure that relevant security policies associated with the transfer of data and the data request via the first computing environment are implemented. The first set of policies includes or represents operations to be performed on the data during the data transfer. Examples of policies in the first set of policies include an antivirus scan policy, a sensitive word detection policy, a data hashing policy, a digital signature policy, and a file type check and routing policy, a code verification policy, a content cleaning policy, a pattern verification policy, and a video transcoding policy. In an example, the first set of policies is applied to the data request using a first security abstraction engine implemented in the first computing environment. A security abstraction engine refers to a software component that implements rules or policies related to access and functionality of data, device resources, and network resources. The security abstraction engine is cloud-scale deployable, does not rely on specialized or export-controlled hardware, and abstracts the implementation of customer-specific security controls. The security abstraction engine provides a reliable base code library that can be configured to meet individual customer needs and implements unidirectional data flows using a software-defined network that is inaccessible to customers or third parties.

[0018] After applying the first set of policies, the data request is transferred as part of the first unidirectional data flow to a second computing environment of the OWT system. The first computing environment and the second computing environment are separated by at least one security boundary of the OWT system using, for example, a border protection device (e.g., a gateway, a router, a firewall, a shield, and an encrypted tunnel). In some examples, a second set of policies associated with the second computing environment is applied to the data request to ensure that relevant security policies associated with the data and the data request transferred to the second computing environment are implemented. In such examples, the second set of policies is applied to the data request using a second security abstraction engine implemented in the second computing environment.

[0019] The data request is provided to a second bi-directional mechanism in the second computing environment to complete the first unidirectional data flow. The second bi-directional mechanism retrieves response data for the data request from one or more data sources accessible to the second computing environment as part of an asynchronous second unidirectional data flow. Alternatively, the first unidirectional data flow is completed and the second unidirectional data flow is initiated after the second bi-directional mechanism retrieves the response data. In either scenario, the transaction identifier for the first unidirectional data flow is assigned to or associated with the second unidirectional data flow. In some examples, at least one of the data sources is located in a computing environment external to the second computing environment (such as a third computing environment in the OWT system or a computing environment external to the OWT system). In at least one example, a third set of policies associated with the second computing environment are applied to the response data to ensure that relevant security policies associated with the transfer of data and data requests via the second computing environment are enforced. The third set of policies are applied to the response data using a third security abstraction engine implemented in the second computing environment.

[0020] The response data is transferred to the first computing environment of the OWT system as part of the second unidirectional data flow. In some examples, a fourth set of policies associated with the first computing environment are applied to the response data to ensure that relevant security policies associated with the data and data requests transferred to the first computing environment are enforced. In such examples, the fourth set of policies are applied to the response data using a fourth security abstraction engine implemented in the first computing environment. The response data is provided to a first bi-directional mechanism in the first computing environment to complete the second unidirectional data flow. The first bi-directional mechanism then provides the response data to the requestor based on the transaction identifier to complete the data request. For example, the first bi-directional mechanism matches the transaction identifier in the data request with the transaction identifier in the response data to determine that the response data is related to the data request. As such, the adoption of the first and second bi-directional mechanisms in the OWT system enables operational action functionality to be implemented by using two asynchronous unidirectional transactions associated by a common transaction identifier to effectively provide synchronous command functionality across data boundaries of the OWT system. This operational action functionality is transparent to the data requestor, thus providing a seamless, synchronous user experience.

[0021] The operational action functionality also enables filtering or modification of response data transferred between various computing environments according to different security policies and requirements of the computing environment. Different security policies and requirements can cause response data to include different attributes when provided to different devices or components of the requesting computing environment. As one example, a first instance of a computing environment implementing a first set of policies submits a data request and produces response data that includes a user (e.g., employee) record that includes a globally unique identifier (GUID). A second instance of a computing environment implementing a second set of policies submits the same data request and produces response data that includes an employee record that includes a globally unique identifier (GUID) and an email address. A third instance of a computing environment implementing a third set of policies submits the same data request and produces response data that includes an employee record that includes an employee name.

[0022] Figure 1 An example system for implementing a bidirectional application programming interface (API) that enables operational action functionality in an OWT system is shown. As presented, system 100 is a combination of interdependent components that interact to form an integrated whole. The components of system 100 can be hardware components or software components (e.g., APIs, modules, runtime libraries) implemented on and / or executed by hardware components of system 100. In one example, the components of system 100 are distributed across multiple processing devices or computing systems.

[0023] In Figure 1 In particular, system 100 represents an OWT system for transferring data between different computing environments. System 100 includes computing environments 102 and 104 and service environment 116. In examples, computing environments 102 and 104 are implemented in a cloud computing environment or another type of distributed computing environment and adhere to one or more distributed computing models / services (e.g., infrastructure as a service (IaaS), platform as a service (PaaS), software as a service (SaaS), function as a service (FaaS)). In some examples, service environment 116 is implemented locally in one or more of computing environments 102 and 104. For example, one or more computing devices in computing environments 102 and / or 104 can each include a separate instance of service environment 116. In other examples, service environment 116 is implemented separately from one or more of computing environments 102 and 104. For example, service environment 116 can be implemented in a cloud computing environment that is remotely accessible by computing environments 102 and / or 104 via a network such as a private area network (PAN), a local area network (LAN), or a wide area network (WAN).

[0024] While Figure 1It is described as a specific combination of computing environments and devices, but the size and structure of the devices and computing environments described herein can vary, and may include additional components or more. Figure 1 The components described herein are fewer. Furthermore, although it will be described in the context of the OWT system and data transfer between low-security and high-security computing environments. Figure 1 The examples shown in the accompanying figures are similar to those in the OWT system, but these examples are equally applicable to data transfer between non-OWT systems and computing environments of various (or similar) types and security levels. Furthermore, these examples are also applicable to data transfer between components of a single device. For example, a bidirectional API can be implemented on a single device with containers (e.g., software data structures for storing data and data objects) that have different policies and access privileges to ensure that network traffic received by one container (e.g., a high-security container) cannot be accessed by another container within that container (e.g., a low-security container).

[0025] about Figure 1 Computing environment 102 represents a low-security computing environment, wherein computing environment 102 is not trusted by computing environment 104 (e.g., devices executing within computing environment 102 are not trusted by devices executing within computing environment 104). In this example, computing environment 102 may be physically separated from computing environment 104, such that computing environment 102 is in a first physical location (e.g., a region, building, or room), while computing environment 104 is in a different second physical location. Alternatively, computing environment 102 and computing environment 104 may share the same physical location.

[0026] The computing environment 102 includes a computing device 108. Examples of the computing device 108 include data diodes and server devices such as web servers, file servers, application servers, and database servers. The computing device 108 receives input such as a data request 110 from a user or computing device within or accessible to the computing environment 102. The data request 110 can include or request one or more types of data (e.g., audio data, touch data, text-based data, gesture data, and / or image data), computing instructions (e.g., commands or operations), and / or data items (e.g., documents or files). As one example, the data request 110 can request data stored by the system 100 or related to one or more components or services of the system 100 (e.g., health or performance data). As another example, the data request 110 can cause a report to be generated or a maintenance operation to be performed. As yet another example, the data request 110 can include a document or file to be stored or processed. The data request 110 is associated with a transaction identifier that identifies a use case, transaction, or source identifier (e.g., an identifier of the computing device 108, an identifier of a component of the computing device 108, or an identifier of a source endpoint providing data to the computing device 108) associated with the data request 110. The transaction identifier is included in (e.g., embedded in or appended to) the data request 110.

[0027] In response to receiving the data request 110, the computing device 108 can access a service environment 116. In examples, the service environment 116 provides access to various computing services and resources (e.g., applications, devices, storage, processing capacity, networking, analytics, intelligence). In examples, the service environment 116 provides access to computing services and resources that are not available to the computing environment 102. Figure 1 In examples, the service environment 116 includes bidirectional API(s) 120 and security abstraction engine(s) 122. One or more bidirectional APIs 120 and / or one or more security abstraction engines 122 can service each of the computing environments 102 and 104. For example, a first bidirectional API 120 and a first security abstraction engine 122 can be associated with data ingress actions of the computing environment 102 (e.g., data transfers from the computing environment 102 to the computing environment 104), and a second bidirectional API 120 and a second security abstraction engine 122 can be associated with data egress actions of the computing environment 104 (e.g., data transfers from the computing environment 104 to the computing environment 102).

[0028] The bidirectional API(s) 120 serve as a front-end layer for sending and retrieving data across multiple computing environments of the system 100. The bidirectional API(s) 120 abstract the data transfer process, such that a user submitting a data request treats the data request data stream and corresponding response data stream as a single bidirectional transaction. As such, the bidirectional API(s) 120 effectively provide an asynchronous command function across data boundaries of the system 100. In some examples, the bidirectional API(s) 120 provide or are associated with a user interface that enables a user to generate and submit data requests. For example, the computing device 108 and / or 112 can provide a graphical user interface (GUI) that enables a user to specify or select data to be retrieved from one or more data sources accessible by the computing environments 102 and / or 104. In other examples, the bidirectional API(s) 120 receive data requests that have been submitted to the computing device 108 and / or 112 via different components or devices of the computing environments 102 and 104.

[0029] The bidirectional API(s) 120 maintain a record of transaction identifiers that identify the data requests 110. For example, the bidirectional API(s) 120 can store the transaction identifiers in a data structure (e.g., a database or memory table) that associates transaction identifiers with data requests 110, users, user devices, user accounts, and / or user sessions. In examples, the bidirectional API(s) 120 apply routing information to the data requests 110 to enable transmission of the data requests 110 across boundaries of one or more computing environments. The routing information includes internet protocol (IP) addresses, media access control (MAC) addresses, uniform resource locators (URLs), and / or device ports. In some examples, the routing information is based on the transaction identifiers. For example, the transaction identifiers can be stored in a routing table that associates transaction identifiers with particular destination addresses or data source identifiers. In such examples, the bidirectional API(s) 120 use the transaction identifier of a data request 110 to identify corresponding destination information in the routing table. Based on the destination information, routing information is applied to the data request 110. The bidirectional API(s) 120 then provide the data request 110 to the security abstraction engine(s) 122 as part of a first unidirectional data stream.

[0030] The security abstraction engine(s) 122 are software engines that abstract security controls that are traditionally dedicated hardware components for policy enforcement. In an example, the security abstraction engine(s) 122 apply a set of policies to the data request 110. Applying the first set of policies includes performing one or more operations associated with the first set of policies on the data request 110. Each operation can be a set of executable instructions that are performed serially by the security abstraction engine(s) 122 or in parallel with other operations. The set of policies includes policies that specify data content and data types that can be provided to and / or received from the computing environments 102 and 104. Such policies can include anti-virus scanning, sensitive word detection, data hashing, digital signature creation / verification, file type checking and routing, code verification (e.g., source code and compiled code verification), data sanitization, schema verification (e.g., file schema and data schema verification), and / or video and audio transcoding. In a specific example, the set of policies includes schema verification policies that describe and verify the structure and content of XML documents.

[0031] Each of the security abstraction engine(s) 122 can provide the same set of policies. Alternatively, one or more security abstraction engines 122 can apply fewer, additional, or different policies than the other security abstraction engine(s) 122. For example, the security abstraction engine(s) 122 associated with the computing environment 102 can apply a first set or first type of policies, while the security abstraction engine(s) 122 associated with the computing environment 104 can apply a second set or second type of policies. The first set or first type of policies can be more restrictive or less restrictive than the second set or second type of policies. Additionally, the security abstraction engine(s) 122 associated with a first unidirectional data flow (e.g., an incoming data flow) can apply a first set or first type of policies, while the security abstraction engine(s) 122 associated with a second unidirectional data flow (e.g., an outgoing data flow) can apply a second set or second type of policies.

[0032] In some examples, the security abstraction engine(s) 122 evaluate policies applied to the data request 110 by other components of the system 100. For example, the service environment 116 can also include a policy engine (not shown) that is distinct from the security abstraction engine(s) 122. The policy engine is a software engine that applies policies to data transmitted using the system 100. The policy engine can apply one or more of the set of policies to the data request 110, or apply different policies to the data request 110. In such examples, the security abstraction engine(s) 122 evaluate the policies applied by the policy engine. For example, the security abstraction engine(s) 122 can evaluate digital signatures created for each policy or operation applied by the policy engine to the data request 110. Evaluating a digital signature includes comparing the digital signature (or attributes of the digital signature) to an expected digital signature (or expected attributes of the digital signature) of the policy applied by the policy engine to determine whether the digital signature is valid.

[0033] The security abstraction engine(s) 122 can include various policy enforcement components for implementing the set of policies. Each of these policy enforcement components can represent a different, specialized hardware device that is used for policy enforcement in a conventional policy enforcement system. In one example, the security abstraction engine(s) 122 implement a code processing function, a complex document processing function, and a video processing function. The code processing function is assigned to process software artifacts (such as software libraries, executable files, software builds, etc.). The code processing function verifies that content included in the data request 110 is of a particular type (e.g., a software artifact type), and can perform additional functions such as compiling source code, verifying code, or generating a digital signature for the file. The complex document processing function is assigned to process complex documents, which refer to documents that include document objects other than text and / or images (e.g., charts, tables, macros, and other executable content) (such as PDF documents, XML documents, presentation documents, spreadsheet documents, etc.). The complex document processing function performs content standardization such as removing content (e.g., macros and images) from the data request 110 and reformatting the content of the data request 110. The video processing function is assigned to process video data (such as video files or video streams). The video processing function processes video content (e.g., modifies the aspect ratio, frame rate, color, and other attributes of the video content), and transcodes content included in the data request 110 using one or more data compression and data decompression utilities (such as codecs).

[0034] After applying the set of policies to the data request 110, the security abstraction engine(s) 122 transmit the data request 110 to the computing environment 104 based on the transaction identifier. For example, routing information associated with the transaction identifier can be used to identify one or more devices or locations in the computing environment 104. In an example, the computing environment 104 represents a more secure computing environment relative to the computing environment 102. The computing environment 104 includes a computing device 112. Examples of the computing device 112 include those described above with respect to the computing device 108. In some examples, the computing device 112 is located proximate to the computing device 108 (e.g., in the same building or room). For example, the computing device 112 and the computing device 108 can be located in the same room of a data center, such that the computing device 108 is located in a first data rack (e.g., a server rack or data cabinet) and the computing device 112 is located in a second data rack or a different tier of the first data rack. In such examples, the computing device 108 and the computing device 112 can be directly connected via a point-to-point cable. In other examples, the computing device 112 is located remotely from the computing device 108 (e.g., in a different building or room).

[0035] In Figure 1 the computing device 108 provides the data request 110 to the computing device 112. In other examples, the security abstraction engine(s) 122 provide the data request 110 to the computing device 112 or to the bidirectional API(s) 120 associated with the computing environment 104. In either scenario, the first unidirectional data flow for the data request 110 can terminate when the computing device 112 or the bidirectional API(s) 120 associated with the computing environment 104 receives the data request 110. Alternatively, the first unidirectional data flow for the data request 110 can terminate after the computing device 112 or the bidirectional API(s) 120 have performed one or more processing steps for the data request 110. For example, the transaction identifier for the data request 110 can be identified and recorded in a temporary storage table.

[0036] In response to receiving the data request 110, the computing device 112 or the bidirectional API(s) 120 access the data store(s) 114. In some examples, the access to the data store(s) 114 initiates or is part of a second unidirectional data flow that is separate from but related to the first unidirectional data flow. The data store(s) 114 include various documents, files, applications, services, and / or other data resources. Examples of the data store(s) 114 include directly attached storage devices (e.g., hard disk drives, solid state drives, and optical disk drives), network-based storage devices (e.g., storage area network (SAN) devices and network attached storage (NAS) devices), and other types of memory devices. While the data store(s) 114 are depicted as being included in the computing environment 104, one or more data stores 114 can be located outside of the computing environment 104. Figure 1

[0037] The data store(s) 114 provide response data 124 associated with the data request 110 to the computing device 112 or the bidirectional API(s) 120. For example, the response data 124 can include one or more data items. Alternatively, the response data 124 can include a completion status (e.g., success, failure, in progress) or an acknowledgement (e.g., the request was received) of one or more requested actions associated with the data request 110. The computing device 112 or the bidirectional API(s) 120 associate the response data 124 to the transaction identifier of the data request 110. For example, the transaction identifier is embedded in or attached to the response data 124. Subsequently, as part of the second unidirectional data flow, the computing device 112 or the bidirectional API(s) 120 transmit the response data 124 to the security abstraction engine(s) 122 based on the transaction identifier. For example, the bidirectional API(s) 120 can access a data structure (e.g., a database or a memory table) that associates the transaction identifier with routing information that specifies a particular destination address or data source identifier. The bidirectional API(s) 120 apply the routing information to the response data 124 to enable the response data 124 to be transmitted to a destination outside of the computing environment 104.

[0038] ​As discussed above, the security abstraction engine(s) 122 can apply a set of policies to the response data 124 and transmit the response data 124 to the computing device 108 or the two-way API(s) 120 associated with the computing environment 102. In the computing environment 102, the transaction identifier associated with the response data 124 is matched to the transaction identifier of the data request 110. For example, the transaction identifier associated with the response data 124 is identified and used to search a routing table for a corresponding transaction identifier associated with the data request (e.g., the data request 110). Upon identifying a matching transaction identifier in the routing table, the response data 124 responsive to the data request 110 is provided. For example, the response data 124 is provided to the requestor of the data request 110 to complete the data request 110 and terminate the second unidirectional data flow.

[0039] Figure 2 An example process flow for completing a data request using a two-way API that implements operational action functionality is shown. In the example, the process flow 200 is performed using an OWT system that includes two or more computing environments, such as computing environments 202 and 204, that are each partitioned by one or more data boundaries of the OWT system. The computing environments 202 and 204 are similar in type and implementation to the computing environments 102 and 104, respectively. Figure 1 For example, the computing environment 202 can represent a publicly accessible business computing environment, while the computing environment 204 can represent a sovereign computing environment that stores data for an entity (e.g., a user, an organization, or a nation) such that the data complies with local laws or policies of the entity and is only accessible by the entity (or by specific members authorized by the entity).

[0040] In the process flow 200, a user interface (UI) 210 of the computing environment 202 receives a data request associated with the computing environment 204. The UI 210 can be provided by a computing device (such as the computing device 108) in or external to the computing environment 204. In the example, the UI 210 enables a user to generate and submit data requests to retrieve data from and / or perform tasks in the computing environments 202 and 204. The UI 210 can also provide data presentation and manipulation functionality (e.g., plotting, reporting, data creation or modification) and provide access to one or more data repositories. For example, the UI 210 can access a data repository that includes performance data (e.g., CPU metrics, memory metrics, disk storage metrics, input / output (I / O) operation metrics) of one or more devices, services, or applications accessible by the computing environment 202.

[0041] In an example, the UI 210 performs one or more processing steps on the data request. For example, the UI 210 associates the data request with a transaction identifier that indicates a data transfer use case (e.g., retrieving or sending data from or to a particular computing environment or a particular type of computing environment, scheduling a task or event, performing a task for a particular entity), a data flow type (e.g., an incoming data flow or an outgoing data flow), a source identifier, and / or a destination identifier. The transaction identifier can be automatically applied to the data request at the time the data request is created or received. The UI 210 also applies one or more annotations and / or metadata to the data request (e.g., source and destination identification and routing information, an expected response data type, status information associated with the data request or a current user session). For example, the UI 210 can apply a message wrapper that includes message header information and routing information for components in the computing environment 202 and / or 204 to the data request.

[0042] The UI 210 transmits the data request to a bidirectional API 212 that is functionally similar to the bidirectional API(s) 120 of the computing environment 200. Figure 1 Upon receiving the data request, the bidirectional API 212 initiates a first unidirectional data flow for the data request. As part of the first unidirectional data flow, the bidirectional API 212 maintains information that associates the data request with a transaction identifier for the data request. For example, the bidirectional API 212 can store a record that associates the transaction identifier with connection information (e.g., a connection and port combination) for a device that provides the UI 210. In some examples, the connection to the UI 210 (and / or a corresponding user session) remains open as the data request is transmitted to a destination to facilitate a synchronous data transfer experience. In other examples, the connection to the UI 210 (and / or a corresponding user session) is closed after the data request is provided to the bidirectional API 212 to facilitate an asynchronous data transfer experience.

[0043] The bidirectional API 212 can assign higher order routing information to the data request based on the transaction identifier. For example, the bidirectional API 212 can wrap the data request (or a message wrapper for the data request) in a message wrapper that includes routing information for a destination or component of the computing environment 202 or 204. The routing information applied by the bidirectional API 212 can be similar to or the same as the routing information applied by the UI 210, thereby leveraging the routing information applied by the UI 210. The bidirectional API 212 transmits the data request to a security abstraction engine 214 that is functionally similar to the security abstraction engine(s) 122 of the computing environment 200, and similar to the security abstraction engines 220, 228, and 234. Figure 1

[0044] ​The security abstraction engine 214 applies a first set of policies to the data request. The first set of policies specifies the content of the request (e.g., data content, document type, data request type, and / or task request type) that can be transmitted from the computing environment 202 to the computing environment 204. For example, the first set of policies can include policies for antivirus scanning, sensitive word detection, data hashing, digital signature creation / verification, file type checking and routing, code verification (e.g., source code and compiled code verification), data sanitization, schema verification (e.g., file schema and data schema verification), and / or video and audio transcoding. As a result of applying the first set of policies, content in the data request can be removed, added, or modified. Alternatively, the data request can be terminated or divided into one or more sub-requests.

[0045] In some examples, the policy engine 216 provides one or more policies of the first set of policies to the security abstraction engine 214. The policy engine 216, which is functionally similar to the policy engines 216, 230, and 236, is a compliance analyzer and rules engine that provides a user interface for building static rules and policies and machine learning (ML)-based rules and policies. The policy engine 216 can provide policies to the security abstraction engine 214 according to a time interval (e.g., every hour, every day, or on an irregular basis) or based on a specified event (e.g., detection of a new data request or a reboot of a component in the computing environment 202). The security abstraction engine 214 then adds one or more of the policies provided by the policy engine 216 to the first set of policies stored or accessible by the security abstraction engine 214. In other examples, the policy engine 216 applies one or more policies of the first set of policies to the data request. For example, the bidirectional API 212 can provide the data request to the policy engine 216 before providing the data request to the security abstraction engine 214. Alternatively, the security abstraction engine 214 can provide the data request to the policy engine 216. In either scenario, the policy engine 216 applies the policies to the data request and provides the data request to the security abstraction engine 214 for further transmission.

[0046] In examples, the security abstraction engine 214 and / or the policy engine 216 identifies the first set of policies to be applied to the data request based on the transaction identifier. As one example, a data structure (e.g., a data table, a data array, or a data map) stores correlations between respective transaction identifiers, policy sets, and / or source identifiers. Each transaction identifier in the data structure can be associated with a different use case and a different set of policies. The security abstraction engine 214 and / or the policy engine 216 uses the transaction identifier in the data request to identify a matching transaction identifier in the data structure. Thereafter, the first set of policies is identified based on the correlation between the transaction identifier in the data structure and the first set of policies in the data structure.

[0047] After applying the first set of policies to the data request, the security abstraction engine 214 transmits the data request to the computing system 218. The computing system 218 includes one or more computing devices, such as the computing devices 108 and 112 of FIG. 1. The computing system 218 transmits the data request from the computing environment 202 to a security abstraction engine 220 in the computing environment 204. In some examples, the security abstraction engine 220 applies a second set of policies to the data request. The second set of policies specifies the content of requests that can be received from the computing environment 202 and / or transmitted to a bidirectional API 224. The second set of policies can include one or more policies or policy types in the first set of policies. As discussed above with respect to the security abstraction engine 214 and the policy engine 216, the policy engine 222 can provide one or more policies of the second set of policies to the security abstraction engine 220 and / or apply the policies to the data request. In at least one example, the security abstraction engine 220 does not apply the second set of policies to the data request. Figure 1

[0048] The security abstraction engine 220 transmits the data request to the bidirectional API 224, which is functionally similar to the bidirectional API 212. The bidirectional API 224 unencapsulates (e.g., removes one or more message wrappers from) the data request to identify a destination associated with the data request. As one example, the data request can indicate a data store, application, or service in or accessible to the computing environment 204. The bidirectional API 224 submits the data request to a UI 226, which is functionally similar to the UI 210. The UI 226 accesses the destination identified by the data request to retrieve the requested data or perform (or cause to be performed) the requested action. Upon retrieving response data (e.g., the requested data or a completion status of the requested action), the UI 226 performs one or more processing steps on the response data. For example, the UI 226 associates the response data with a transaction identifier associated with the data request. Associating the response data with the transaction identifier includes retrieving the data request and applying (e.g., appending or embedding) the transaction identifier to the response data. In some examples, the UI 226 applies one or more annotations and / or metadata to the response data and applies message wrappers to the response data that include message header information and routing information for components in the computing environments 202 and / or 204. In at least one example, the routing information for the response data is selected based on the transaction identifier. For example, the UI 226 and / or the bidirectional API 224 can access a data structure that stores a correlation between transaction identifiers and corresponding routing information (e.g., a connection and port combination) for the device providing the UI 210.

[0049] ​UI 226 provides the response data to the bidirectional API 224. In some examples, the first unidirectional data flow terminates when the bidirectional API 224 receives the response data from the UI 226. In other examples, the first unidirectional data flow terminates when the bidirectional API 224 receives the data request from the security abstraction engine 220. In either scenario, the bidirectional API 224 initiates a second unidirectional data flow to provide the response data to the requestor upon completion of the data request.

[0050] Upon receiving the response data, the bidirectional API 224 can assign higher order routing information to the response data based on the transaction identifier, as discussed above, to utilize the routing information applied by the UI 226. The bidirectional API 224 transmits the response data to the security abstraction engine 228. The security abstraction engine 228 applies a third set of policies to the response data. The third set of policies dictate the response content (e.g., data content, document type, and / or response type) that can be transmitted from the computing environment 204 to the computing environment 202. For example, the third set of policies can include policies defining authorized recipients and authorized days / times of data transmission in addition to, or in lieu of, the policies included in the first and / or second set of policies. As a result of applying the third set of policies, content in the response data can be removed, added, or modified. Alternatively, the response data can be deleted or divided into one or more sub-responses. As discussed above with respect to the security abstraction engine 214 and the policy engine 216, the policy engine 230 can provide one or more of the third set of policies to the security abstraction engine 228 and / or apply the policies to the response data.

[0051] After applying the third set of policies to the response data, the security abstraction engine 228 transmits the response data to the computing system 232. The computing system 232 is functionally similar to the computing system 218. The computing system 232 transmits the data request from the computing environment 204 to the security abstraction engine 234 in the computing environment 202. In some examples, the security abstraction engine 234 applies a fourth set of policies to the response data. The fourth set of policies dictate the response content that can be received from the computing environment 204 and / or transmitted to the bidirectional API 212. The fourth set of policies can include one or more of the policies or policy types in the third set of policies. As discussed above with respect to the security abstraction engine 214 and the policy engine 216, the policy engine 236 can provide one or more of the fourth set of policies to the security abstraction engine 234. In at least one example, the security abstraction engine 234 does not apply the fourth set of policies to the response data.

[0052] The security abstraction engine 234 transmits the response data to the bidirectional API 212. The bidirectional API 212 decapsulates (e.g., removes one or more message wrappers from) the response data request to identify a destination associated with the response data. The response data indicates a user, computing device, or storage location to which the response is to be provided. For example, the response data can indicate connection information for the device providing the UI 210. In some examples, the bidirectional API 212 transmits the response data to the UI 210 using an open connection, completing the data request in a synchronous manner. For example, the bidirectional API 212 can transmit the response data to the UI 210 using a connection (and / or user session) that remains open after being used to submit the data request from the UI 210 to the bidirectional API 212. In such examples, the bidirectional API 212 can identify the open connection based on the transaction identifier. For example, the transaction identifier in the response data can be matched to a transaction identifier associated with the open connection to determine that the open connection is to be used to transmit the response data to the UI 210. In other examples, the bidirectional API 212 transmits the response data to the UI 210, completing the data request in an asynchronous manner. For example, the bidirectional API 212 opens a new connection with the UI 210 based on routing information for the response data, and transmits the response data to the UI 210 using the new connection.

[0053] The UI 210 receives the response data from the bidirectional API 212 and provides the response data to the requestor of the data request. In some examples, the second unidirectional data stream terminates when the UI 210 provides the response data to the requestor. In other examples, the second unidirectional data stream terminates when the UI 210 receives the response data from the bidirectional API 212. In either scenario, the use of the first unidirectional data stream and the separate second unidirectional data stream (as opposed to the use of a single bidirectional data stream) enables operational action functionality across data boundaries of the OWT system.

[0054] Having described a system that can be employed by embodiments disclosed herein, a method that can be performed by such a system is now provided. While the method 300 is described in the context of the system 100 of Figure 1 the processing flow 200 of FIG. 2, performance of the method 300 is not limited to these examples. Figure 2

[0055] Figure 3 ​A method 300 for transmitting and receiving data in an OWT system using bidirectional APIs is shown. In an example, bidirectional APIs are implemented in an OWT system that includes multiple computing environments. One or more of the computing environments can be different in security level or physical location. For example, one of the computing environments can be a low-security environment, while another of the computing environments can be a high-security environment. The OWT system can be configured such that a source endpoint and / or a destination endpoint of data transmitted over the OWT is unknown to one or more of the computing environments.

[0056] The method 300 begins at operation 302, where a data request, such as the data request 110, is received at a first bidirectional API, such as the bidirectional API(s) 120. Receiving the data request at the first bidirectional API initiates a first unidirectional data flow. The first bidirectional API is implemented in or provided by a first device, such as the computing device 108, that is located in a first computing environment, such as the computing environment 102, of the OWT system. In an example, the data request includes one or more types of data (e.g., audio data, touch data, text-based data, gesture data, and / or image data), computing instructions (e.g., commands or operations), and / or data items (e.g., documents or files). The data request can indicate data to be retrieved or one or more actions to be performed (e.g., scheduling a task, generating a notification, executing a file or set of commands). The data request is associated with a transaction identifier that is included in (e.g., embedded in or attached to) the data request. In some examples, the transaction identifier is applied to the data request by the first bidirectional API upon receiving the data request. In other examples, the transaction identifier is applied to the data request prior to being received by the first bidirectional API. For example, as part of generating the data request, an interface used to generate the data request, such as the UIs 210 and 226, can assign the transaction identifier to the data request.

[0057] In at least one example, the first bi-directional API maintains a record of the transaction identifier by storing the transaction identifier in a first data structure that associates transaction identifiers with data requests. The first data structure can also associate the transaction identifier with a use case, connection information (e.g., IP address and port information for an open or closed connection between the first bi-directional API), or a source identifier of a user (e.g., a username or user account), a source identifier of a user device (e.g., a device name or MAC address), or a source identifier of a user object (e.g., a container or storage location associated with the user). In such an example, the first bi-directional API applies routing information associated with the transaction identifier to the data request to enable transmission of the data request across data boundaries of the OWT system. The transaction identifier can be associated with a use case that specifies routing information for performing the use case. For example, the use case can specify a source address of the data requestor, a destination address of a data repository or service that has access to the requested data, and / or one or more intermediate destination addresses (e.g., a security abstraction engine, a policy engine, a computing system, an address of a bi-directional API). In an example, applying the routing information to the data request includes applying a message wrapper to the data request and including the routing information in the message wrapper.

[0058] At operation 304, the first set of policies is applied to the data request. In an example, the first bi-directional API provides the data request to a first security abstraction engine (such as the security abstraction engine(s) 122). The first security abstraction engine identifies the first set of policies based on the transaction identifier to apply to the data request. For example, the first security abstraction engine can search a second data structure that associates transaction identifiers with the first set of policies and / or with a policy engine that provides the policies associated with the transaction identifier. The first set of policies includes policies that specify data content, file types, and task request types that can be transmitted from the first computing environment. For example, the first set of policies can include policies for anti-virus scanning, sensitive word detection, data hashing, digital signature creation / verification, file type checking and routing, code verification, data sanitization, schema verification, and / or video and audio transcoding. The first security abstraction engine applies the identified first set of policies to the data request by performing one or more operations associated with the first set of policies on the data request. Each operation can be a set of executable instructions that are performed serially or in parallel with the other operations. In one example, a digital signature is generated for each policy or operation to verify that the policy or operation has been successfully performed.

[0059] At operation 306, the data request is transmitted to a second computing environment (such as computing environment 104) of the OWT system. In an example, the first security abstraction engine provides the data request to a first computing system (such as computing system 218). The first computing system transmits the data request to the second computing environment based on the routing information. For example, a computing device in the first computing system identifies a transaction identifier or routing information in a message wrapper of the data request. The computing device then transmits the data request to a computing device or component in the second computing environment based on the transaction identifier or routing information.

[0060] In some examples, the first computing system transmits the data request to a second security abstraction engine. As discussed above, the second security abstraction engine identifies a second set of policies based on the transaction identifier to apply to the data request. The second set of policies includes policies that specify data content, file types, and task request types that can be received from the first computing environment or transmitted by the second computing environment. For example, the second set of policies can include those in the first set of policies. The second security abstraction engine applies the second set of policies to the data request and transmits the data request to the second bidirectional API. In other examples, the first computing system transmits the data request directly to the second bidirectional API.

[0061] At operation 308, the data request is fulfilled. In an example, the second bidirectional API processes the data request to identify a destination from which to retrieve data or to be accessed to perform a task associated with the data request. Processing the data request includes unmarshaling (e.g., removing one or more message wrappers from) the data request to identify a destination of the data request. The destination can be a storage location (such as data store(s) 114), a service or application, or an interface (such as UI 226). In at least one example, one or more destinations associated with the data request are external to the second computing environment. The second bidirectional API accesses the destination and performs one or more actions associated with the data request. As one example, the second bidirectional API performs a search query in a database for an item or document indicated by the data request. As another example, the second bidirectional API causes a service or application to store data provided in the data request. As yet another example, the second bidirectional API causes a source code file provided in or indicated by the data request to be compiled and / or deployed to a secure environment.

[0062] In response to performing the action associated with the data request, the second bi-directional API receives response data associated with the data request from the destination. In an example, the response data includes one or more data items, references to data items, a completion status, and / or other data and metadata related to the data request (e.g., data request metrics, data item metadata, data request modifications). For example, in addition to including a set of documents, the response data can include metadata for the set of documents (e.g., document creation dates, document sizes, document authors), an indication of one or more documents that were omitted from the response data, and an explanation for the omission of the documents (e.g., the requestor was not authorized to access the documents, the destination or the second computing environment does not allow the transmission of the documents outside the boundaries of the second computing environment, the data request was modified during transmission to the second bi-directional API). The first unidirectional data flow terminates upon receipt of the response data at the second bi-directional API.

[0063] At operation 310, the second bi-directional API processes the response data. In an example, the second bi-directional API initiates a second unidirectional data flow for providing the response data to the requestor by performing one or more processing steps on the response data. As one example, the second bi-directional API associates a transaction identifier for the data request with the response data. For example, the transaction identifier can be appended to or embedded within the response data. The second bi-directional API applies routing information associated with the transaction identifier to the response data to enable the transmission of the response data across the data boundaries of the OWT system. For example, the second bi-directional API can access a third data structure that includes a correlation between transaction identifiers and routing information for destinations associated with the transaction identifiers. In an example, applying the routing information to the response data includes applying a message wrapper to the response data and including the routing information and / or the transaction identifier in the message wrapper.

[0064] At operation 312, a third set of policies is applied to the response data. In an example, the second bi-directional API provides the response data to a third security abstraction engine. As discussed above, the third security abstraction engine identifies the third set of policies to apply to the response data based on the transaction identifier. The third set of policies includes policies that specify data content and file types that can be transmitted from the second computing environment to particular users or computing environments. For example, the third set of policies can specify that restricted data (e.g., user medical data) is not authorized to be transmitted outside the second computing environment, confidential data (e.g., user demographic data) is authorized to be transmitted to the first computing environment and not authorized to be transmitted to the third computing environment, and public data (e.g., user usage data) is authorized to be transmitted to the first computing environment and the third computing environment. The third set of policies can include those policies in the first set and / or the second set of policies.

[0065] At operation 314, the response data is transmitted to the first computing environment of the OWT system. In an example, the second security abstraction engine provides the response data to the second computing system (such as computing system 232). The second computing system transmits the response data to the first computing environment based on the routing information. For example, a computing device in the second computing system identifies the transaction identifier or routing information in the message wrapper of the response data. The computing device then transmits the response data to a computing device or component in the first computing environment based on the transaction identifier or routing information.

[0066] In some examples, the second computing system transmits the response data to a fourth security abstraction engine. As discussed above, the fourth security abstraction engine identifies a fourth set of policies based on the transaction identifier to apply to the response data. The fourth set of policies includes policies that specify data content, file types, and task request types that can be received from the second computing environment or transmitted by the first computing environment. For example, the fourth set of policies can include those in the first set, the second set, and / or the third set of policies. The fourth security abstraction engine applies the fourth set of policies to the response data and transmits the response data to the first bidirectional API. In other examples, the second computing system transmits the response data directly to the first bidirectional API.

[0067] At operation 316, the response data is provided to the source component upon completion of the data request. In an example, the first bidirectional API processes the response data to identify a destination associated with the response data. Processing the response data includes un-encapsulating (e.g., removing one or more message wrappers from) the response data to identify the transaction identifier. The transaction identifier is used to identify connection information or a source identifier associated with the data request. For example, the first bidirectional API uses the transaction identifier to search a first data structure for a matching transaction identifier entry. The matching transaction identifier entry includes a connection and port combination of a source component (e.g., a computing device, service / application, or interface) that was used to generate and / or submit the data request to the first bidirectional API. In one example, the first bidirectional API uses a connection that has remained open since transmitting the data request to the second computing environment to provide the response data to the source component. In this example, using the open connection to provide the response data to the source component facilitates a synchronous data transfer experience. In another example, the first bidirectional API opens a new connection to the source component using the connection information. For example, the first bidirectional API can use an IP address listed in the connection information of the source component. However, the first bidirectional API can use a different port associated with the source component to open the new connection to the source component. In this example, using the new connection to provide the response data to the source component facilitates an asynchronous data transfer experience. The second unidirectional data stream terminates when the response data is provided to the source component.

[0068] Figures 4-5The associated descriptions provided in connection with various operations described herein are provided to illustrate and not to limit the scope of the various aspects of the disclosure. Contemplated Figures 4-5 The devices and systems illustrated and discussed are for purposes of example and illustration and can be

[0069] Figure 4 is a block diagram illustrating physical components (e.g., hardware) of a computing device 400 with which aspects of the disclosure can be practiced. The computing device components described below can be suitable for the computing devices and systems described above. In a basic configuration, computing device 400 includes at least one processing system 402 and system memory 404. Depending on the configuration and type of computing device, system memory 404 can comprise volatile memory (e.g., random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM)), flash memory, or any combination.

[0070] System memory 404 includes operating system 405 and one or more program modules 406, such as one or more components supported by the systems described herein, suitable for running software applications 420. For example, operating system 405 can be suitable for controlling the operation of computing device 400.

[0071] Furthermore, embodiments of the disclosure can be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Embodiments of the disclosure can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices. Figure 4 The basic configuration in Figure 4 includes at least one processing system 402 and system memory 404. Depending on the configuration and type of computing device, system memory 404 can comprise volatile memory (e.g., random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM)), flash memory, or any combination.

[0072] As described above, a number of program modules and data files can be stored in system memory 404. While executing on the processing system 402, the program modules 406 (e.g., an application 420) can perform processes including, for example, the aspects described herein. Other program modules that can be used in accordance with aspects of the present disclosure can include electronic mail and contacts applications, word processing applications, spreadsheet applications, database applications, slide presentation

[0073] Furthermore, embodiments of the disclosure can be practiced in an electrical circuit comprising discrete electronic elements, packaged or integrated electronic chips containing logic gates, a circuit utilizing a microphone, or a single chip containing electronic elements or Figure 4 Each of the components or many of the components illustrated in FIG. 17 can be integrated on a single integrated circuit. Such a SOC device can include one or more processing units, graphics units, communications units, system virtualization units, and various application functionality all of which are integrated (or "burned") onto the chip substrate, depending upon the embodiments. When operating via a SOC, the functionality, described herein, for client handoff protocol capabilities can be operated via application-specific logic integrated with other components of the computing device 400 on the single integrated circuit (chip). Embodiments of the disclosure can also be practiced using other technologies capable of performing logical operations such as AND, OR, and NOT, including but not limited to mechanical, optical, fluidic, and quantum technologies. In addition, embodiments of the disclosure can be practiced within a general computer system, a computer system designated for

[0074] The computing device 400 can also have one or more input device(s) 412 such as a keyboard, a mouse, a pen, a sound or voice input device, a touch or swipe input device, etc. Output device(s) 414 such as a display, speakers, a printer, etc. can also be included. The aforementioned devices are examples and others can be used. The computing device 400 can include one or more communication connections 416 allowing communications with other computing devices 450. Examples of suitable communication connections 416 include, but are not limited to, radio frequency (RF) transmitter, receiver, and / or transceiver circuitry; universal serial bus (USB), parallel, and / or serial ports.

[0075] The term computer readable media as used herein can include computer storage media. Computer storage media can include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, or program modules. The system memory 404, the removable storage device 407, and the non-removable storage device 410 are all computer storage media examples (e.g., memory storage.) Computer storage media includes RAM, ROM, electrically erasable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other article of manufacture which can be used to store information and which can be accessed by the computing device 400. Any such computer storage media can be part of the computing device 400. Computer storage media does not include a modulated data signal or other propagated or modulated data signals.

[0076] Communication media can be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" can describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, communication media can include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0077] Figure 5 One aspect of a system architecture for processing data received at a computing system from a remote source, such as a personal computer 504, a tablet computing device 506, or a mobile computing device 508, is illustrated, as described above. The content displayed at the server device 502 can be stored in different communication channels or other storage types. For example, various documents can be stored using a directory service 522, a web portal 524, a mailbox service 526, an instant messaging store 528, or a social networking site 530.

[0078] The input evaluation service 520 can be employed by a client in communication with the server device 502, and / or the input evaluation service 520 can be employed by the server device 502. The server device 502 can provide data, and receive data from client computing devices, such as the personal computer 504, the tablet computing device 506, and / or the mobile computing device 508 (e.g., a smart phone), over the network 515. By way of example, the computer systems described above can be embodied in the personal computer 504, the tablet computing device 506, and / or the mobile computing device 508 (e.g., a smart phone). In addition to receiving graphics data that can be pre-processed at a graphics generation system or post-processed at a receiving computing system, any of these embodiments of computing devices can obtain content from the data store 516.

[0079] It will be appreciated from the present disclosure that one example of the technology discussed herein relates to a system comprising: a processing system; and a memory coupled to the processing system, the memory comprising computer executable instructions that, when executed, perform operations of: receiving, at a first bidirectional application programming interface (API) in a first computing environment of an one-way transfer (OWT) system, a data request, the data request associated with a transaction identifier; applying, using a first security abstraction engine, a first set of policies to the data request; transmitting the data request to a second computing environment of the OWT system; receiving, from the second computing environment, response data associated with the data request; and providing, based on the transaction identifier, the response data responsive to the data request.

[0080] In another example, the technology discussed herein relates to a method comprising: accessing, at a first bidirectional application programming interface (API) in a first computing environment of an one-way transfer (OWT) system, first data, the first data associated with a transaction identifier; applying, in the first computing environment, a first policy to the first data using a first policy engine; transmitting the first data to a second bidirectional API in a second computing environment of the OWT system, wherein the first computing environment and the second computing environment are separated by a data boundary of the OWT system; receiving, through the second bidirectional API, second data associated with the first data; applying, using a second policy engine in the second computing environment, a second policy to the second data; and providing the second data to the first computing environment.

[0081] In another example, the technology discussed herein relates to a one-way transfer (OWT) environment comprising: a processing system; and a memory comprising computer executable instructions that, when executed, perform operations of: receiving, at a bidirectional application programming interface (API) in a first computing environment of a one-way transfer (OWT) system, first data, the first data being associated with a transaction identifier and representing a first one-way data stream; applying, based on the transaction identifier, a first set of policies to the first data using a first policy engine; transmitting the first data to a second computing environment of the OWT system; receiving second data associated with the first data, the second data representing a second one-way data stream; applying a second set of policies to the second data, wherein the first set of policies is different than the second set of policies; transmitting the second data to the first computing environment; and providing the second data to the first computing environment.

[0082] Aspects of the disclosure are described above with reference to flowchart illustrations and / or block diagrams of methods, systems, and computer program products according to aspects of the disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. Such computer program instructions can be provided to a processor of a computer, or other programmable data processing apparatus, to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0083] The description and drawings of one or more aspects provided herein are not intended to limit or restrict the scope of the claimed disclosure in any way. The aspects, examples, and details provided herein are considered sufficient to convey possession of the general inventive concepts disclosed herein to others skilled in the art. The claimed disclosure should not be construed as being limited to any aspect, example, or detail provided herein. Regardless of whether a particular feature, structure, or example is described in the context of one or more aspects, examples, or details, it should be understood that such features, structures, or examples can be employed in any other aspect, example, or detail described or illustrated herein. Various features, structures, and characteristics (both physical and methodological) described or illustrated herein can be chosen as optimal for a particular implementation, based on design and operational considerations. After reading and understanding the description and drawings of the one or more aspects provided herein, those skilled in the art will appreciate the modifications, permutations, and alternatives having essentially the same scope as the one or more aspects provided herein.

Claims

1. A system (100) comprising: Processing system (402); as well as A memory (404) coupled to the processing system (402), the memory (404) including computer-executable instructions that, when executed, perform operations including: A data request (302) associated with a transaction identifier is received at a first bidirectional application programming interface (API) in a first computing environment of the One-Way Transmission (OWT) system; The first security abstraction engine is used to apply the first set of policies (304) to the data request; The data request is transmitted (306) to the second computing environment of the OWT system; Receive (314) response data associated with the data request from the second computing environment; and Based on the transaction identifier, provide (316) the response data in response to the data request.

2. The system (100) according to claim 1, further comprising: In response to receiving the data request in the second computing environment, a second bidirectional API in the second computing environment is invoked; The response data associated with the data request is retrieved (308) via the second bidirectional API; The second set of policies is applied (310) to the response data using the second security abstraction engine; as well as The response data is transmitted (314) to the first computing environment.

3. The system (100) according to claim 1, wherein the first computing environment: Not trusted by the second computing environment; and When the data request is in the second computing environment, the data request cannot be tracked.

4. The system (100) of claim 1, wherein the transaction identifier indicates a use case for the data request, the use case describing at least one of user objectives or routing information for the data request.

5. The system (100) according to claim 1, wherein the first bidirectional API storage: The correlation between the transaction identifiers; and A first connection between the first bidirectional API and the source component, the first connection being used to provide the data request to the first bidirectional API.

6. The system (100) according to claim 5, wherein: The first connection remains open while the response data is retrieved from the second computing environment; and The first bidirectional API uses the first connection to provide the response data to the source component to facilitate the synchronous data transmission of the data request and the response data.

7. The system (100) according to claim 5, wherein: After the first bidirectional API receives the data request from the source component, the first connection is closed; In response to receiving the response data, the first bidirectional API opens a second connection with the source component; as well as The first bidirectional API uses the second connection to provide the response data to the source component to facilitate asynchronous data transmission of the data request and the response data.

8. The system (100) of claim 1, wherein receiving (302) the data request at the first bidirectional API comprises: Based on the transaction identifier, routing information is applied to the data request through the first bidirectional API, the routing information indicating a route to the second computing environment or a destination in the second computing environment; as well as A message wrapper is applied to the data request, the message wrapper including the routing information.

9. The system (100) of claim 1, wherein the first set of policies specifies at least one of the following: data content, file type, or task request type authorized to be transferred from the first computing environment to the second computing environment.

10. The system (100) of claim 2, wherein transmitting the data request (306) to the second computing environment comprises: The data request is transmitted to a third security abstraction engine in the second computing environment, wherein the third security abstraction engine specifies at least one of the following: Authorized to receive from the first computing environment or transmit by the second computing environment: Data content; File type; or Task request type; as well as Before providing the response data to the second bidirectional API, the third set of policies is applied (312) to the data request through the third security abstraction engine.

11. The system (100) according to claim 2, wherein retrieving (308) response data includes: Remove the message wrapper from the data request to create an unwrapped data request; The destination indicated by the unpackaged data request is identified via the second bidirectional API; as well as Perform an action at the destination to receive the response data.

12. The system (100) of claim 2, wherein the second set of policies specifies at least one of data content or file types authorized to be transferred from the second computing environment to the first computing environment.

13. The system (100) of claim 2, wherein transmitting the response data (314) to the first computing environment comprises: The response data is transmitted to the first bidirectional API via the second security abstraction engine.

14. The system (100) of claim 1, wherein providing (316) the response data in response to the data request comprises: The response data is provided to the interface used to submit the data request to the first bidirectional API, which is implemented in the first computing environment.

15. A method (300) comprising: Access (302) first data at a first bidirectional application programming interface (API) in a first computing environment of a one-way delivery (OWT) system, the first data being associated with a transaction identifier; The first policy engine in the first computing environment is used to apply the first policy (304) to the first data; The first data is transmitted (306) to the second bidirectional API in the second computing environment of the OWT system, wherein the first computing environment and the second computing environment are separated by the data boundary of the OWT system; Receive (308) second data associated with the first data via the second bidirectional API; The second policy engine in the second computing environment is used to apply the second policy (312) to the second data; as well as Provide the second data (314) to the first computing environment.

16. The method (300) according to claim 15, wherein: The first data indicates the task to be performed in the second computing environment; and The second data indicates the completion status of the task.

17. The method (300) of claim 15, wherein the second bidirectional API associates the transaction identifier with the second data so that the second data can be transmitted to the first computing environment.

18. The method (300) of claim 15, wherein the first strategy is identified by matching the transaction identifier to a corresponding transaction identifier stored in a data structure, the data structure associating the corresponding transaction identifier with the first strategy.

19. The method (300) according to claim 15, wherein: The second strategy prevents unauthorized data from being transferred from the second computing environment to the first computing environment; and The first strategy is different from the second strategy.

20. A one-way transmission (OWT) system (200), comprising: Processing system (402); as well as A memory (404) includes computer-executable instructions that, when executed, perform operations, including: First data is received at a bidirectional application programming interface (API) in the first computing environment of the One-Way Transmission (OWT) system, the first data being associated with a transaction identifier and representing a first one-way data stream; Based on the transaction identifier, the first strategy engine is used to apply (304) the first set of strategies to the first data; The first data is transmitted (306) to the second computing environment of the OWT system; Receive (308) second data associated with the first data, the second data representing a second unidirectional data stream; Apply the second set of strategies (312) to the second data, where the first set of strategies is different from the second set of strategies; The second data is transmitted (314) to the first computing environment; and Provide the second data (316) to the first computing environment.

Images