The Middle Man

The Need for a Cross Domain Communication Reference Architecture

2013-08-16T20:51:00.000-04:00

Secure Cross Domain Communication (CDC) has been a critical concern in the recent past particularly for the US Intelligence Community. Secure protocols for CDC has drawn significant thrust from the intelligence community, industry, and academia alike. Yet, coordination of activities between different (security) domains remains a crucial challenge. Cross-domain data flows often require extensive human reviews that are both time-consuming and error-prone. A partial survey of current cross-domain security solutions revealed, among others, the following issues:

From the perspective of mission applications design, current CDC solutions require mission application programs to design and implement their own individual solutions around particular guard designs, resulting in vendor lock-ins. Developers have to learn guard interfaces, design architectures for interacting with them, incorporate CDC concepts into their specific applications, and manage accreditation for the resulting systems
From the perspective of enterprise security infrastructure, guard products are typically transport oriented. This would require the guard to have the highest security privilege in order to be able inspect inform passing through it, contrary to best security practices. Furthermore, this implies same security terminology is required for both domains connected by the guard. For example, the same set of security labels have to be used. Such an assumption is not always true, especially when the information exchange across organizational boundaries. Last but not least, associating the guards with the links often fails to scale as the number of security domains increase, such as in the interagency cases, commonly known as the “n squared problem”.
CDC guards often have limited configurability and API. The result will be a proliferation of locked-in stacks that will reduce purchasing flexibility and increase program development expense.

In addition, current CDC solutions require excessive amount of human intervention, mainly due to the lack of a standard and flexible framework for describing information. Many guards use dirty word list or some rudimentary rules expressed in XSLT to filter information passing through them. These techniques often fail to take into account the context of messages and meaning of the words, leading to false positives or negatives. Human review is often required to adjudicate ambiguities, leading to critical delays in the workflow.

Most of the CDC solutions today focus on one or more particular aspects of cross-domain communications, for example, filtering information in web (HTTP) traffic. To understand the multi-faceted nature of cross domain communication, we need to a conceptual framework in which interactions among CDC participants can be abstracted out, forming the basis for protocols.

To highlight the issues that the reference architecture needs to address, let us consider the simple use case shown above. In this example,

A user submits a classified travel request through a Mission Planning System (MPS).
The MPS then sends a web service request to a Financial Management System (FMS), which is part of an unclassified network/domain.
When the classified travel request passes through the guard, all classified information (itinerary) in the request needs to be redacted, allowing the rest of the message to pass as is.
The FMS sends an email via SMTP to the mail server for the approver’s review. Since the mail server is on the classified network/domain, the guard needs to restore the redacted content for the approver to see the request in its entirety.
The approver accesses the mail server from his/her classified workstation.

In reality, the workflow is likely to be more complex. But, the simplified example above is sufficient and suitable for our discussions. Consider the following questions raised by this use case.

How is the guard included in the workflow?

a. If the guard is transparent to the mission application, then does the application need to be notified in case the guard blocks the message?

b. If, on the other hand, the guard is an active participant in the workflow, would the guard “proxy” the target system by exposing the same web service interface? In other words, should the mission application address the request to the guard, instead of the financial management system?

c. In (b), can the guard hide the identity of the source/target systems for security reasons – For instance, can the guard certify to the mission that the message is delivered to the proper target system, without revealing the identity of the system?

d. Can the guard act as the information brokers across domain as well? For instance, can the guard locate the appropriate recipient in the correct domain for a particular message?

How does the guard determine which content to redact and which to allow without redaction?

a. Is there a standard vocabulary that the guards and mission application share to describe the information, the actors, the security labels, and the security actions?

Is a single guard or multiple guards monitoring both Web Service and SMTP traffic on the network/domain?

a. Or should the guard just monitor TCP/IP packets without knowledge of application level protocols?

b. If there are two different guards, how do they coordinate with each other? In the above example, how would a Web Service guard and an email guard coordinate to restore the redacted information for the approver?

A reference architecture will not provide standard answers to these questions. Rather, it will delineate responsibilities among various CDC participants, and describe how they interact with one another. As such, it will allow design choices like these to be made by the designers and/or architects of – infrastructure, mission application(s), guard products, etc., based on their unique business needs.

CDC is a shared responsibility between the CDC infrastructure and the mission application taking advantage of such an infrastructure. For the purpose of protocol design, we are primarily concerned with the infrastructure aspects of CDC. That is, standardized interfaces for products (hardware or software) whose primary responsibility is to facilitate secure cross-domain communications. A security guard is one such product, and perhaps the most important.

As shown in the diagram, the reference architecture needs to address the following concerns-

Architecture Concerns: We believe it is reasonable to assume that mission applications are aware of the fact that they interact with system in other security domains, and therefore, the presence of security guards. It is the application’s responsibility to properly handle the cases where a message is rejected by the guard for security reasons.
Policy Concerns: Security attributes for application-specific messages need to be defined so that proper security policies can be enforced by the infrastructure. We consider this an application concern in the sense that the security attributes are associated with individual data elements processed by the application, even though it is likely that a security administrator attaches these security attributes at runtime.
Network Concerns: Specifically, the reference architecture needs to address the concerns of how the guard(s) interacts with the network. Any protocol needs to address how CDC-specific communications (messages between the application and the guard as well as messages between the guards) are carried in the network protocols. For example, how such messages are carried in a SOAP message for web services-based communications or in the HTTP header for web traffic. Doing so could require extensions to existing protocols so that security-specific information could be added to the messages. A particular aspect of integrating guard with network protocol is a mechanism to handle end-to-end encryption and authentication. For example, if a mission application encrypts payload using WS-Security, the guard would not be able inspect the message content unless the message is addressed to the guard (instead of the target system) and encrypted using the guard’s keys.
Information Concerns: Specifically, how guards interact with information floating through them. We believe there need to be a convention for determining how application-specific messages are interpreted and acted upon by the guards, while the goal of enabling: 1) Automation, so that time-consuming and error-prone human reviews can be reduced and, in some cases, eliminated; 2) Interoperability, so that CDC solutions from multiple vendors can work together seamlessly, and vendor lock-ins is avoided.
Workflow Concerns: Specifically, how guards interact with other participants of the workflow, i.e. mission application and other guards. Compared to the others, there has not been extensive research on this aspect of CDC. Much less discussion about how existing standards such as Business Process Modeling Notation (BPMN) languages can be leveraged for CDC. One important workflow consideration is whether or not the guard is an active participant in the workflow, and if so, how does the guard act as a service intermediary.

Our presentation at 10th International Semantic Web Conference (ISWC)

2011-12-01T15:20:00.001-05:00

http://iswc2011.semanticweb.org/fileadmin/iswc/Papers/Industry/Extending_SOA_infrastructure_Alion.pptx

Extending SOA Infrastructure for Semantic Interoperability

2011-07-22T14:51:00.002-04:00

Our talk at the DoD SOA Symposium is now available. In this talk, we presented an ontology-based run-time infrastructure to enable semantic service interoperability, as an extension to traditional SOA infrastructures which generally include Service Registries and Enterprise Service Buses (ESB)

The Concept of a Semantic Mediation Bus™

2011-07-01T01:15:00.001-04:00

When it comes to implementing services, ontologies are still very much viewed as a tool to help developer to write code, instead of as part of a runtime solution.

We will present a different approach at the 3rd DoD SOA and Semantic Technology Symposium next month. A semantic mediation bus™ (SMB) enables semantic interoperability through common ontologies, even when the services are implemented using different data models and message standards. The SMB is built on top of an Enterprise Service Bus (ESB), extending SOA infrastructure beyond their traditional role of protocol adoption and message transformation. This solution leverages open standards including Web Ontology Language (OWL) and Semantic Annotations for WSDL and XML Schema (SAWSDL). SAWSDL plays a critical in our solution because it provides the link between service descriptions and the common ontology, thus allowing the mediation infrastructure to determine the compatibility between two service interfaces.

Corporation through federation, instead of standardization is the principle behind using ontology as the tool to describe message meaning. The ontology driven approach avoids imposing a standard that has to be agreed by everybody, which is especially important when information needs to be shared across organizational boundaries. By allowing each organization to select the standards best suited for their business needs, while still able to use services offered by the larger community.

A Recent Paper

2009-10-28T15:58:00.000-04:00

We have recently published a paper titled "Refactoring J2EE Application for JBI-Based ESB: A Case Study". It was presented at EDOC 2009 conference:

http://www.computer.org/portal/web/csdl/doi/10.1109/EDOC.2009.25

Integration of Web Service Stacks in an ESB

2009-06-15T16:39:00.000-04:00

Slides from the BOF session at JavaOne

View more Microsoft Word documents from bfmj4fj.

Enhancing the Role of a Large U.S. Federal Agency as an Intermediary in the Federal Supply Chain via a Service Registry and a JBI-Based ESB

2009-06-13T16:06:00.000-04:00

We did a technical session at JavaOne

http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-4389&yr=2009&track=soa

WOA is neither SOA nor REST

2009-04-02T17:37:00.000-04:00

I admit that I am only catching up on the whole Web Oriented Architecture (WOA, See What Is WOA? It's The Future of Service-Oriented Architecture (SOA) ) buzz. But I don’t think it is true that Web-Oriented Architecture" to represent the concept of "SOA plus REST", because based on my reading of the definition, it is neither:

A WOA is not a SOA because it is not description oriented. Without a description language such as WSDL, publishing and subscribing to services becomes problematic.
A WOA is not REST because it does address “state transfer” part of REST. While I can see WOA works well in many simple cases of web application design, I believe it needs to be complement with, yes, traditional SOA, and semantic web technologies to solve complex problems, for one simple reason: not all service interactions can be modeled as CRUD.

Let’s take a very simple example: travel reservation. Let’s assume that the travel agent has implemented a WOA style service. So a client (any client on the web) can create a Reservation (Resource identified by a URI) through a simple HTTP PUT. Let’s say the Reservation is “on hold” initially. And a representation (let’s assume XML) of the Reservation is return to the client:

<reservation xmlns="…">
<flight>UA989</flight>
<date>2009-04-01Z</date>
<status>Held</status>
</reservation>

Now, maybe a day later, the client wants to purchase this reservation. What should it (since the client is not a human being in our case) do? The logical options are

1. Do an HTTP POST with a new Reservation.

<reservation xmlns="…">
<flight>UA989</flight>
<date>2009-04-01Z</date>
<status>Purchased</status>
</reservation>

But the problem is how we can ensure that the user does not change other parts of the reservation like Flight. If the answer is the system simply ignores the Flight information on a POST, how can we make that constraint known to any client on the web?

2. Do a partial update, in which case you probably need to define a whole protocol like WSRT

3. Make the Status a separate Resource. So, you would do

POST /Reservation/20090401UA989_1234/Status HTTP/1.1
… …
Purchased

The problem here is how does the client extract information about the link between resources /Reservation/20090401UA989_1234 and /Reservation/20090401UA989_1234/Status from the representation of the Reservation as, per Fielding,

A REST API should be entered with no prior knowledge beyond the initial URI
(bookmark) and set of standardized media types that are appropriate for the
intended audience (i.e., expected to be understood by any client that might use
the API). From that point on, all application state transitions must be driven
by client selection of server-provided choices that are present in the received
representations or implied by the user’s manipulation of those representations

Of course we can bring RDF in to solve this, but it is not clear how semantic web fits in the WOA stack.

Service Composition, Service Mediation, and the role of WSDL

2008-11-26T00:51:00.000-05:00

It does not seem like we’ll get a break from the whole SCA vs. JBI controversy any time soon. Until the industry agree on what proper relationship between them should be, I don’t think there is any real hope for JBI 2.0, which is really sad for those of us advocating for a standard based ESB.

So, how should SCA and JBI work together? The answer always depends on who you ask. From the JBI perspective, JBI provides a platform for service mediation, while SCA can be used for composing these services for a particular business purpose (a composite application). From the SCA perspective, SCA is for making composite applications and JBI can be used as a specific SCA binding.

I have been thinking about the subtle difference between service composition and service mediation. Service composition, as SCA correctly pointed out, is about grouping platform independent services together to serve a business purpose. The key point is that the platform specific concerns are left to specific bindings, which is probably close to the soaML work that is going on at OMG. In many ways, composite application can thought as a programming model – when you are designing a composite application on a SCA platform, you need to know SCA! (On the other hand, an application developer designing a service should not be aware of an ESB, whether it is JBI based or not)

Service mediation is about providing a common platform at runtime for service interactions, which implies a few things, the most important being the need for a common way to describe services. For that, I think we have pretty much settled on WSDL and WS-Policy. I think the JBI approach, i.e., ESB endpoints described using WSDL and an NMR based the WSDL 2.0 message exchange patterns, provides a better mediation platform.

The role WSDL plays in service mediation is also recognized by SCA – the use of Mediation Modules shows that. But if WSDL is good enough for bridging SCA with the external world, why aren’t they good enough to describe the internal ESB endpoints that make up a composite application?

Web Service Support in JBossESB

2008-11-13T20:31:00.000-05:00

I made an assertion that JBossESB 4.4 did not come with an out-of-the-box SOAP listener. As a result, a user has two options to get a SOAP over HTTP message onto the ESB:

Process the message on the ESB through an HTTP listener. The draw back is that is that the payload of the ESB message will be the SOAP envelope instead of domain objects. And the listener will not be able to support WS-* since it does not process SOAP headers.

Process the SOAP message with a web service hosted in JBossWS. This “ESB-aware” web service then pushes an ESB message to the ESB message through the service invoker interface, as shown in diagram below. The advantage of this approach is that QoS policies, including WS-*, can be enforced by the web service. The disadvantage is that the user will not take advantage of the ESB’s support for transport protocol bindings.

I was immediately challenged because some marketing material had said that JBossWS is now part of the ESB. First, that is not what the JBoss download page says:

The jbossesb-server binary distribution is a pre-configured profile based on the JBoss Microkernel architecture. The ESB Server comes pre-installed with JBoss messaging, JBoss Webservices, all of the base ESB capabilities and is the best choice for those who want to get started quickly.

The jbossesb binary distribution is a standalone distribution of JBoss ESB. The distribution comes with installation scripts allowing it to be installed into a full JEE
application server, if required.

Aside from the marketing, however, I think what got people confused is the fact that JBossWS hosted web service can be exposed as an ESB endpoint through the SOAPProcessor action. (Oh, the web service can even be deployed with the ESB achieve…..So great! :)

But what gets exposed by SOAPProcessor is really an ESB endpoint, not a web service endpoint, as pointed by JBossESB Programmer’s Guide:

The SOAPProcessor action allows you to expose JBossWS 2.x and higher Webservice Endpoints through endpoints (listeners) running on the ESB (“SOAP onto the bus”). This allows you to use JBossESB to expose Webservice Endpoints (wrapper Webservices) for services that don't expose a Webservice Interface. JBossWS Webservice Endpoints exposed via this JBossESB action are “ESB Message Aware” and can be used to invoke Webservice Endpoints over any transport channel supported by the ESB.

To be precise, in this approach, JBossWS acts as a service container for some POJO programmed to the conventions of JAX-WS. Because the web service endpoint is not exposed by the ESB through SOAPProcessor action, you will still need to use one of the two alternatives outlined above, as suggested in the diagram below.