Creating end to end security

There are many potential end to end security scenarios. Each of these might involve differing security steps. Several typical scenarios, with the necessary security options, are presented.

Before you begin

These scenarios all assume that global security is enforced.

Why and when to perform this task

Steps for this task

  1. Determine which of the examples provided in this section, most closely match your security needs. In certain instances, your scenario will involve a combination of information from more than one of the examples.
  2. Read the security information for the relevant scenarios and apply it to your security needs.

Classic integration scenario - inbound and outbound adapters

An inbound request comes in from a WebSphere Business Integration Adapter. The service component architecture (SCA) invokes an interface map based on the SCA export. The request flows through a process component, a second interface map and is then passed on to a second EIS (B), via a WebSphere Adapter. These are SCA invocations, with one component invoking a method on the next component.

The figure shows a progression of data through a classic integration scenario. From left to right the information starts in an EIS, labelled "A", passes through a WebSphere Business Integration Adapter, to an SCA JMS Export, through an interface map to a process. The process then passes the request through a second interface map and an SCA Import to a WebSphere Adapter which then communicates with a second EIS, labelled "B". All the elements except the two EISs and the WebSphere Business Integration Adapter are grouped into an ellipse, labelled "WebSphere Process Server". An arrow shows the direction of data flow.

There is no authentication mechanism for the inbound adapter. You can establish the security context by defining the SecurityIdentity qualifier on the first component - in this instance, the first interface map component. From that point, SCA will propagate the security context from each component to the next. Access control for each component is defined by use of the SecurityPermission qualifier.

Inbound Web service request to WebSphere Process Server

In this scenario a Web service client invokes a WebSphere Process Server component. The request passes through several components in the WebSphere Process Server environment before being passed to an EIS by an adapter.

The figure shows a Web service request to WebSphere Process Server. On the left is a cell labelled "WebServices client" an arrow from this cell, with the label "SSL or WS security" points to an ellipse labelled "WebSphere Process Server" which contains unlabelled cells intended to represent various processes, adapters and maps. From this ellipse a second arrow emerges, labelled "SSL" which leads to a cell representing an EIS.

You can authenticate the Web service client as a SSL client, using HTTP Basic authentication or using WS-Security authentication. When the client is authenticated, access control is applied based on the SecurityPermission qualifier. Between the client and the WebSphere Process Server instance, you can secure the data integrity and privacy using SSL or WS-Security. SSL secures the entire pipe, whereas with WS-Security you can encrypt or digitally sign parts of the SOAP message. For Web services, WS-Security is the preferred standard.

Outbound Web service request from WebSphere Process Server

In this scenario the inbound request can be from an adapter, a Web service client, or a HTTP client. WebSphere Process Server a component (for instance a BPEL component) invokes an external Web service.

The figure shows a Web service request from WebSphere Process Server. On the left is a cell labelled "EIS A" an arrow from this cell, with the label "SSL" points to an ellipse labelled "WebSphere Process Server", from this ellipse two arrows emerge, the first, labelled "SSL or WS security" terminates at a cell labelled "External WebService", the second labelled "SSL" leads to a cell representing a second EIS (B).

As for the inbound Web service request, you can authenticate with the external Web service as a SSL client, using HTTP Basic authentication or using WS-Security authentication. Use LTPACallBackHandler as the callback mechanism to extract the usernameToken from the current RunAs subject. Between WebSphere Process Server and the target Web service, you can ensure data privacy and integrity using WS-Security.

Web application - HTTP inbound request to WebSphere Process Server

WebSphere Process Server supports three types of authentication for HTTP:
  • HTTP basic authentication
  • HTTP forms based authentication
  • HTTPS SSL-based client authentication.
In addition, to protect your intranet from intruders, you can place the Web server in the demilitarized zone (DMZ), and the WebSphere Process Server inside the inner firewall. In this example, Webseal is used as the reverse proxy, which performs the authentication. It has a trust association with WebSphere Process Server behind the firewall and can forward authenticated requests.
The figure depicts a web application making an HTTP (inbound) request to WebSphere Process Server. From left to right, the figure comprises a triangular cell, labelled "HTTP or WebService Client", from which an arrow emerges, which crosses a thick line representing a firewall and terminates at a pentagonal cell, labelled "Webseal". A second firewall isolates this Webseal cell, in a region denoted "DMZ". From the Webseal cell an arrow emerges (labelled "SSL), which crosses the second firewall and arrives at a cell labelled "WebSphere Process Server". Following the sam trajectory as the previous two arrows a third arrow emerges from the right side of this cell and terminates at cell labelled "EIS". There is a fifth cell in the image, located directly below the "WebSphere Process Server" ellipse. This cell is labelled "Tivoli Access Manager or LDAP", and is connected to the "WebSphere Process Server cell by a vertical double-headed arrow, and also to the "Webseal" cell by a double-headed arrow which crosses the thick line representing the second firewall, this final arrow is labelled "SSL".
Related concepts
Security considerations for service integration buses

Terms of use |

Last updated: Thu Apr 27 14:39:09 2006

(c) Copyright IBM Corporation 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)