Integration with external systems is a key requirement of any real BPM solution. Most of the time this integration can be handled at the server side using the various integration connectors provided by the BPM engine, or by custom connectors built for the project. However, there are some occasions where integrating at the server becomes problematic.
This article discusses the situations that prove difficult to support with server side integrations and describes how having the browser act as an integration middle man can sometimes solve a complex integration problem.
What is Browser Side Integration
Browser side integration takes a number of forms, from the simple case where data from multiple domains is simply displayed on a single web page, to the scenario where an AJAX request retrieves data from one site, processes it, and forwards it to another site or server.
In general, browser side integration is restricted to REST or SOAP requests over HTTP. Though not a technical restriction, more complex integrations likely require access to transport technologies and libraries not available in a browser (such as JMS messaging).
The above diagram illustrates a typical scenario where a client side (browser) application calls a public API from the internet and sends the results to a secure company server that may be locked down.
The secure company server needs no access to the source of the public API, and security is enforced by the users access to the corporate network. Essentially, the trust relationship is delegated to the user responsible for accessing the application.
The following scenarios illustrate typical problems seen in many large scale BPM projects that are easily solved by using Browser Side Integration.
Scenario 1 - Restricted External Access from DMZ
As illustrated in the above diagram, the corporate server is not able to access the public API because of firewall restrictions. Yet, the specific application needs access to a set of document links provided by the US State Department REST API (http://www.state.gov/api/v1).
Options to solve this could include:
- Open the DMZ to alow outbound access to www.state.gov
- Copy all the documents to a local repository
- Retrieve the documents client side
Obviously, if the documents are simply going to be displayed on the page, it makes no sense to open the firewall, and copying the documents may have version and intellectual property implications.
Scenario 2 - Server Not Authorized
Access to a company’s human resources document repository is restricted by user id, yet the security technology used on the BPM server and the Document server are incompatible. As such, requests from the BPM server cannot be authenticated to guarantee they come from an authorized user.
This is a very common scenario where a trust relationship cannot be established between two servers and often arises after corporations merge or otherwise acquire another IT infrastructure.
Here, the long term (strategic) goal may be to merge the security technology stack, but often this can take years.
A tactical solution, since both applications can be accessed via a browser is to perform the integration at the one common node.
Scenario 3 - Service needs to act on behalf of a user
This scenario is similar to scenario 2; however, very often BPM service tasks are expected to access data “on behalf of the user” for audit or access control reasons. This is relatively easy if there are no access controls over the data to be retrieved as most BPM engines are able to collect user id’s of human tasks and pass them through in a subsequent system request.
However, if the target service has access control restrictions, the user credentials will need to be passed with the request in the form of headers, cookies or request parameters. In general, BPM service tasks do not have access to such credentials short of hard coded system credentials that may be declared in the application itself.
Then there is the question of which user should the service be accessing the data as, and what happens if the corporate security policy is managed by a Kerberos, CAS, SPNEGO or similar federated authentication technology where no single request has a user’s credentials and all tokens are only valid one time.
All modern browser’s support federated authentication and have plugins to support single sign on (SSO) or federated authentication models such as SPNEGO, Kerberos and CAS. Meaning, browsers have already solved the problem and trust relationships already exist between the browser and each of the systems data or content is being retrieved from.
Therefore, it only makes sense to distribute the processing and have the browser client side application perform the data retrieval in a secure and trusted way.
The data can then be simply presented or relayed to another server to which the authenticated user has an established trust relationship.
What Techniques and Technologies Exist to Make Browser side integration possible?
Browser side integration typically makes use of the following technologies:
Without AJAX, none of the following techniques will work.
JSONP or JSON with Padding is a commonly used technique to overcome cross site scripting restrictions.
JSONP requires that the server understand a parameter in the request that represents the “padding” function.
If a padding function is provided in the request URL, a link that may previously have returned something like:
Now returns something like:
Now, if you have a function in your client side application called “callbackFunction” then you are successfully able to process the data retrieved from another domain.
The JSONP approach takes advantage of what is known as “script element injection” to get around the same origin policy restrictions.
Dynamic Script Injection
Dynamic script tag injection is a technique in which new <script> elements are created at runtime. When the new <script> is added to the page, its "src" URL is automatically downloaded and executed.
This technique is actually very similar to JSONP in that it exploits the same SOP exposure.
One of the lesser known HTML5 APIs is the window.postMessage.
postMessage provides the ability to send data messages between two windows or frames across domains. Essentially window.postMessage acts as cross-domain AJAX without the need for server customizations that are required to support JSONP and dynamic script injection.
The most useful fact about postMessage is that unlike some of the other HTML5 standards that are not supported by Internet Explorer until IE10, postMessage has been supported by IE since version 8. In fact, the Microsoft Sharepoint Cross Domain library uses the postMessage method to handle cross domain access in Sharepoint web applications (known as app webs).
What about Security?
It is easy to see how using the browser as an integration medium could open a system to potential attacks such as Man in the Middle, trojan horses, or Denial of Service. However, the risks introduced can easily be mitigated by strong network security policies and good application design.
In fact, many of the techniques used for browser side integration are widely used by analytics engines and other product targeting plugins.
To ignore or be unaware of the techniques simply makes a company vulnerable to exploits.
Same Origin Policy
Same Origin Policy is a security technology embedded into all modern browsers that restricts scripts executing on a page from one domain to process data from a page on another domain.
This is an oversimplification as there are other restrictions around image tags, iframes and include, but the one that causes the web developer the most concern is the restriction on scripts.
Doesn’t Cross Site Scripting protection make this technique impossible?
Prior to HTML5, one had to use either JSONP or Dynamic Script Injection techniques to get around a browser’s “same origin policy” restriction. HTML5 introduced two W3C standards that give the web developer and network administrator the power to whitelist certain sites and asset types.
CORS or Cross Origin Resource Sharing is a technology standard introduced in HTML5 to relax the restrictions imposed by Same Origin Policy. CORS works by allowing a content producer to whitelist domains that are able to access their content.
For example, a public API will have a CORS response that includes the following header:
This says than any site that presents an Origin header will be allowed access to the content provided by this site.
A more secure server may expose a header such as this:
This says that only requests coming from foo.com will be able to access content on this site.
CORS goes on to add more features around requiring credentials and enabling only specified methods (GET, HEAD, POST, PUT, DELETE, etc.) so it is possible to be very specific about what sites can access content and what sites are restricted.
CSP or Content Security Policy is an HTML5 standard technology that works along the same lines as CORS, but rather than whitelisting domains that can access specific content like CORS, CSP is defined on the Origin server and defines a whitelist of sites that the application can reach out to for content.
Like CORS, CSP works by injecting headers that are interpreted by browsers to regulate access to remote data.
Content-Security-Policy: script-src 'self' https://apis.google.com
This is a pretty simple example that indicates that applications running on the current origin server are able to load scripts from the apis.google.com domain.
CSP restricts content loading not only by domain and method, but also by content type with the ability to restrict scripts, form submission, images and other media types.
Often the easiest way to integrate data from two incompatible systems is via a node that is able to communicate to both systems. On occasion this node turns out to be a client application running on a browser.
Integrating incompatible systems through a browser is a perfectly reasonable technique as long as the risks are understood and the security devices provided by HTML5 capable browsers are properly implemented.
Where possible, JSONP, dynamic script injection techniques should be avoided, not because they don’t work, but because the implementation either requires customization of the server side in the case of JSONP or that the implementation takes advantage of Same Origin Policy exposures in the case of dynamic script injection.
Rather, a combination of CORS and CSP settings should provide a configuration over coding solution to cross site scripting needs while maintaining a consistent security policy for the application.