Identity federation using SAML and WebSphere software

Supporting identity federation using an Enterprise Service Bus and WebSphere software


This article is centered on the aspects related to Identity Federation across Service-Oriented Architectures and how to support this emerging paradigm using WebSphere® software.

Identity Federation describes use-cases, standards and technologies for enabling the propagation of identity information across different security domains. Several standards are proposed for promoting federation among enterprises, we'll focus the attention mainly on SAML and WS-Security standards. In terms of implementation technology, the Security Assertion Markup Language (SAML) is an XML-based standard developed by the OASIS Security Services Technical Committee, for exchanging authentication and authorization data between security realms, so it can be used to support Identity Federation and able to accomplish identity propagation within an Enterprise and among Enterprises. Nowadays, it's taking place the adoption of SAML as the vehicle used to propagate identity information across a Service Oriented Architecture.

During the article, we’ll show how WebSphere Application Server and Websphere DataPower can act as an Enterprise Service Bus in scenarios where Identity Federation is applied, in these terms detailed use case and examples, coming from real experiences, will provide information on how to handle SAML assertions with the capability introduced by these two products. The article is subdivided into six sections:

  1. An introduction of the basic concepts related to the identity federation paradigm and how a SAML assertion is structured.
  2. A description of a sample scenario where cooperation between two enterprises takes place, illustrating macro interaction among the user, the involved application and enterprises.
  3. A first approach to support identity propagation aspects using WebSphere Application Server basic messaging capabilities introduced from version 6.
  4. A second approach to address the same goal using WebSphere DataPower.
  5. Demonstration of what happens within the sample scenario.
  6. Considerations regarding pros and cons of each showed approach, especially taking in account security and operational aspects that are important when considering an adoption in a "real life environment".

Key elements

  • Identity Federation
  • Security Assertion Markup Language (SAML)
  • WS-Security
  • WebSphere Application Server basic messaging capabilities
  • WebSphere DataPower SOA Appliance

This article assumes familiarity with Web Services technology and the ability to develop and deploy J2EE applications, as well as familiarity with WebSphere Application Server and WebSphere DataPower products.

Identity federation and SAML

The term "Identity Federation" usually describes use-cases, standards and technologies able to enable the propagation of identity information across different security domains. This identity portability is achieved in an open mainly standards-based manner. The intent is to offer open specifications and standards able to supply a broad spectrum of use-cases and interoperability. Identity Federation aims to enable users of one domain to securely access applications, data or services of another domain seamlessly, avoiding the need of further user authentication and its administration. Typical use-cases involve for example web cross-domain SSO, cross-domain user attribute exchange, cross domain applications cooperation. The adoption of Identity Federation paradigm and its standard could drive to several pros like:

  • Cost reduction by improving economy of scale reusing existing services
  • Less data redundancy
  • Better security and lower risk by enabling an organization to identify and authenticate a user once, and then use that identity information across multiple systems, including external partners
  • Privacy improvement by allowing the user to control what information is shared, and limiting the amount of information shared with other partners
  • Better end-user experience by eliminating the need for new accounts registration through automatic "federated provisioning" or avoiding redundantly login through cross-domain single sign-on

Identity Federation can be accomplished any number of ways, some of which involve the use of formal Internet standards, such as the OASIS Security Assertion Markup Language (SAML) specification, as well as some open source proposal like Information Cards, OpenID and the Higgins trust framework. OASIS Security Assertion MarkUp Language provides a markup language for representing security assertions. Assertions are usually created by an asserting party (a.k.a. Identity Provider or IdP) based on a request of some sort from a relying party (a.k.a. Service Provider or SP).

These assertions are created by the entity responsible for security enforcement (such as a security service) to convey its findings to other entities that depend on those findings. SAML, developed by the Security Services Technical Committee of the Organization for the Advancement of Structured Information Standards (OASIS), is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application. Such information is carried by assertions exchanged by asserting parties (who issue the assertion) and the relying party (who receive the assertion for authentication or authorization purpose). SAML specification is organized with a modular approach and is based upon some building blocks that are briefly introduced hereafter (please refer to the Related topics section in order to find more details about SAML).

Figure 1. A typical SAML Modular Structure
A typical SAML Modular Structure
A typical SAML Modular Structure


As already mentioned, assertions carry statements about a principal that an asserting party claims to be true, where the valid structure and contents of an assertion are defined by the SAML assertion XML schema. Assertions are usually created by an asserting party (a.ka. Identity Provider or IdP) based on a request of some sort from a relying party (a.k.a. Service Provider or SP), and they contain statements that service providers use to make access control decisions. Three types of statements are provided by SAML:

  • Authentication statements
  • Attribute statements
  • Authorization decision statements

Authentication statements asserts to the service provider that the principal did certainly authenticate with the identity provider at a particular time using a well-defined method of authentication. Other information about the authentication method used by the principal (called the authentication context) may be enclosed into an authentication statement.

An attribute statement asserts that a subject is associated with certain attributes. An attribute is simply a name-value pair. Relying parties use attributes to make fine grain access control decisions.

An authorization decision statement asserts that a subject is permitted to perform action “A” on resource “R” given evidence “E”.


Protocols describe how assertions are packaged within SAML request and response elements. Corresponding to the three types of statements, there are three types of SAML queries:

  • Authentication query
  • Attribute query
  • Authorization decision query


Bindings, are a mapping of a SAML protocol message onto standard messaging formats and/or communications protocols. For example, the SAML SOAP binding specifies how a SAML message is encapsulated in a SOAP envelope, which itself is bound to an HTTP message.


Profiles describe in detail how SAML assertions, protocols, and bindings combine to support a defined use case.

A sample scenario

Let's assume a sample scenario concerning application cooperation between two hypothetical partners (JHKL Inc. and ACME Inc.), the introduced scenario will rely on the following assumptions:

  • JHKL Inc. makes a service available to the ACME Inc.
  • Web Service technology is used to implement the application-to-application relationships
  • SAML is used for enabling the identity propagation between the two enterprises
Figure 2. A sample case of application-to-application relationship together with identity federation
A sample case of application-to-application relationship together with identity federation
A sample case of application-to-application relationship together with identity federation

Here we assume that both enteprises choose to use the same pattern, implementing an Enterprise Service Bus Gateway (simply ESB Gateway later) specialized to sustain applications cooperation toward external partners. In this way, "Application A" (such as other possible internal applications) doesn't need to change its natural approach to security aspects like identity propagation, since the Enterprise Service Bus Gateway will handle all messages directed to "Application B" adapting them to the Identity Federation rules established with JHKL Inc.

The following sections show how both enterprises realize their own ESB Gateway using a different approach.

What happens when John Doe attempts to access the "Application B"

John Doe is an employee of ACME Inc. working on "Application A" and such as on other internal applications, he already performed an authentication and naturally his credentials has only a local validity and meant. When John Doe triggers a request where "Application A" needs to interact with "Application B", then "Application A" sends the messages to the ESB Gateway who's is in charge of applying all necesssary tasks and between these a security protocol transformation. In fact, here we are assuming that "Application A" belongs to a private domain where ACME Inc. chose WS-Security User-Name Token (simply WS-UNT later) as a common vehicle for enabling identity propagation, so "Application A" normally sends messages containing a user local credential encapsulated into a WS-UNT, the role of the ESB Gateway is to transform this kind of credential in something understandable from JHKL Inc. In order to do so, the ESB Gateway:

  1. Validates and extracts the user's identity from the WS-UNT (for example: "John Doe")
  2. Removes the WS-UNT
  3. Adds a SAML Authentication Assertion (encapsulated into a WS-Security header) containing:
    • The user's identity (for example: "John Doe")
    • Attributes that declare the roles of the user's identity (for example: "Guest")
    • A digital sign that ensures the message integrity such as the provider's identity
  4. Routes the message to the "Application B"

It is important to note how the attribute declaring user's role (for example: "Guest") must be based on a nomenclature established by both ACME Inc. and JHKL Inc. during their business agreement.

What happens within the JHKL Inc.

Still holding the ACME Inc. perspective, here we dont' assume technological details about the implementation of the partner's Information System, but our attention is only focused on which information JHKL Inc. has to handle given a SAML Authentication Assertion. In these terms, given a SAML Assertion, the JHKL Inc. has to:

  1. Validates the digital sign, in order to ensure message's origin and integrity
  2. Extracts the caller's identity (for example "John Doe") and forge a local ephemeral identity, especially for audit purpose (who did and what)
  3. Extracts the caller's role from the assertion's attribute (for example: "Guest"), in order to assign an authorization level to the caller

About last point, JHKL Inc. could also assign a local valid "service" identity to the caller on the basis of his role (for example "Guest"), to address internal identity propagation requirements if, for example, "Application B" requires to apply an authorization process and/or access other secured resources. To address internal identity propagation, taking advantage of the Identity Federation paradigm, JHKL Inc. doesn't need to internally map ACME Inc. identities, but it can make a correlation "m:n" where:

  • "m" is the number of all possible roles established between JHKL Inc. and ACME Inc.
  • "n" is the number of all possible different authorization levels, each one associated with a locally valid service identity

An approach to realize the ESB Gateway of ACME Inc.

ACME Inc. chooses to implement the ESB Gateway essentially using WebSphere Application Server basic capabilities, like the messaging features introduced with version 6. However, beyond WebSphere Application Server product, ACME Inc. had to develop two software components to sustain its architecture, in detail:

  • A custom application (that includes the OpenSAML open source project) that acts as SAML Assertion Provider.
  • A JAX-RPC handler that invokes the SAML Provider from ESB layer
Figure 3. A possible way to realize the ESB Gateway to meet the requirements of ACME Inc.
A possible way to realize the ESB Gateway to meet the requirements of ACME Inc
A possible way to realize the ESB Gateway to meet the requirements of ACME Inc

Looking the above diagram, following what happens when "Application A" attempts to invoke the service exposed by JHKL Inc.

  1. "Application A" sends a SOAP request message containing a WS-UNT
  2. The SOAP Http Listener accepts the message and routes it to the Inbound Service component
  3. The WS-UNT is validated and removed from message, but a security subject (user's identity) takes place
  4. The Inbound Service forwards the message to the Outbound Service component
  5. The JAX-RPC handler adds a SAML Authentication Assertion (built on top of user's identity) into the message invoking the SAML Provider application
  6. The Outbound Service component routes the message to the "Application B"

Implementing the ESB Gateway of "Enterprise A"

The ESB Gateway for "Enterprise A" essentially relies on the Service Integration Bus (SIB), a feature introduced by WebSphere Application Server V6. In order to realize the architecture describe by Figure 2, the following main steps are required:

  1. Deployment of the JAX-RPC handler and SAML Provider application
  2. Enablement of the WebSphere Application Server for Service Data Objects repository
  3. Configuration of a SOAP/HTTP listener within the application server associated to the BUS
  4. Creation of a BUS, such as the outbound and inbound services
  5. Definition of the Web Service WS-Security configuration and binding for the incoming messages and attach them to the inbound service port
  6. Definition the JAX-RPC handler list and attach it to the outbound service port

The purpose of this section is not to provide a step-by-step guide to build the target architecture, since all detailed information about each step can be found into Related topics section. Any way, the following paragraphs provide a brief description for all key elements realizing the ESB Gateway of ACME Inc., supplying more details about those aspects specific of this sample scenario (the JAX-RPC handler, the custom STS application, the web service ws-security configuration and binding).

The Service Data Objects repository

Service Data Objects (SDO) is an open standard for enabling applications to handle data from different data sources in a uniform way, as data graphs. For example, SIB uses the SDO repository for storing and serving WSDL definitions, such mediation programming model provides a SDO interface to all messages and a common API for accessing properties and metadata.

Enabling WebSphere Application Server for SDO is simple and considering our test environemnt where we used a WebSphere Application Server standalone profile, we just executed the following commands:

  1. Open a command window
  2. Change to the <WAS_HOME>/bin directory
  3. Execute the command: wsadmin -f installSdoRepository.jacl -createDb node1 server1"

The above commands install a SDO repository using the embedded Derby database, at the end of the procedure, in WebSphere admin console, you should see a new application called SDO Repository.

The Service Integration BUS and the SOAP/HTTP Listener

WebSphere Application Server V6 introduces a completely new default messaging engine written in Java™ and detailed information about this feature can be found in the Related topics section. However, here we can define the Service Integration Bus (simply BUS later) as a logical cloud, that provides the mechanisms to interconnect a consumers with a providers. This logical cloud contains:

  • Messaging engine: a component hosted by WebSphere Application Server (a single single instance or a cluster) able to communicate messages to the destinations
  • Destination: a logical endpoint to which applications can attach as producers, consumers (or both)
  • Message point: a location hosted by Messaging engines where messages are held for a destination

To realize the sample scenario of Figure 3, we used a sample standalone instance of WebSphere Application Server, to which we configured a BUS that has:

  • The unique standalone WebSphere Application Server as member
  • The Messaging engine hosted by the standalone WebSphere Application Server
  • One "queue" Destination for the Inbound Service
  • One "Web Service" type Destination for the Outbound Service
  • An association with a SOAP/HTTP listener hosted the standalone WebSphere Application Server instance as member

The SOAP/HTTP listener provides the way for a service on the BUS to be invoked, so in the sample scenario it represents the target endpoint for "Application A", when this last one triggers to access the "Application B".

In detail, the URI exposed by the ESB Gateway follows the structure: [SOAP HTTP listener prefix]/soaphttpengine/[BUS's name]/[Inbound Service's name]/[Inbound Service Port's name]

The WS-Security configuration and binding

The ESB Gateway has to apply a security policy in order to accept only incoming SOAP messages containing a locally valid identity, to accomplish this requirement, WS-Security bindings and configurations can be defined and attached to the inbound Bus service port. Information on how to do this step can be found in the Related topics section), however the following tables show the main parameters used to configure WS-Security binding and configuration for a WS-UNT.

Table 1. Properties to define the "request consumer" WS-Security binding
Property nameProperty value
Token consumer class
Part reference nameUsernameToken
Local name
JAAS configuration namesystem.wssecurity.UsernameToken
Table 2. Properties to define the "inbound" WS-Security configuration
Property nameProperty value
Local name of the required security token
Local name of the caller

In the WebSphere admin console, the WS-Security configuration and binding must be configured within the Service Integration menù, as below figure shows.

Figure 4. Where to define WS-Security configurations and bindings
Where to define WS-Security configurations and bindings
Where to define WS-Security configurations and bindings

Successively, the WS-Security configuration and binding must be attached to the Inbound Service port, as below figure shows.

Figure 5. Attaching WS-Security configurations and bindings to the Inbound Service Port
Attaching WS-Security configurations and bindings to the Inbound Service Port
Attaching WS-Security configurations and bindings to the Inbound Service Port

The JAX-RPC Handler

In our scenario, the JAX-RPC handler operates on the incoming traffic (from "Application A"), applying a message transformation able to insert a SAML Authentication Assertion into the incoming messages.

The handler gets a valid signed SAML Assertion invoking the custom SAML Provider application.

Listing 1. JAX-RPC "handleRequest" method
public boolean handleRequest(MessageContext context)
      log(Level.INFO,"handleRequest","Start to handle a SOAP Request");
      SOAPMessageContext soapMsgCtx=(SOAPMessageContext)context;
      SOAPMessage soapMessage=soapMsgCtx.getMessage();

      ByteArrayOutputStream xml=new ByteArrayOutputStream();
      String message=xml.toString();
      log(Level.FINEST,"handleRequest","Message to handle: "+message);

      String subject=WSSubject.getCallerPrincipal();
      if (subject==null)
         log(Level.INFO,"handleRequest","Missing subject");
         return false;
      log(Level.INFO,"handleRequest","Identity found: "+subject);

      Context ctx=new InitialContext();
      STSEngineHome home=(STSEngineHome)ctx.lookup(STS_EJB);
      STSEngine stsEngine=home.create();

      String newMessage=stsEngine.doMessageTransformation(message, subject);

      log(Level.FINEST,"handleRequest","Message produced: "+newMessage);

      return true;
   } catch (Exception e)
      log(Level.INFO,"init","blocking error: "+e.getMessage());
      return false;

Looking the source at Listing 1, the bold lines show the points where the handler:

  1. Gets the user's identity from WebSphere layer, as a result of the creation of a subject after the WS-Security policy applying
  2. Invokes the SAML Provider application (via RMI-IIOP), providing both message and identity, for getting a new message containing a signed SAML Authentication Assertion

The SAML Provider application

In extreme syntehsis, the SAML Provider application makes available the function:

f-transformation(Message, Identity) :Message

The application asks for a message and an identity, then it gives back a new message containing a SAML Authentication Assertion. SAML Provider is an Enterprise Application containing one Enterprise Java Bean module, since the transformation function is implemented by a Session Enterprise Java Bean (the source at Listing 2 shows the remote interface), this last one relies to the OpenSAML project to produce signed SAML Assertions.

Listing 2. The EJB home interface that implements the SAML Provider

 * Remote interface for Enterprise Bean: STSEngine
public interface STSEngine extends javax.ejb.EJBObject {

public String doMessageTransformation(String message,String subject)
throws Exception;

Considering the Assertions producing, this activity has important implications regarding governance, system management, implementations and so on, such as:

  • Management of digital certificates required for digital signing
  • Being able to assign a role to a given identity

Regarding the information management in terms of mapping between local identities and roles established with JHKL Inc, in our scenario the SAML Provider application simply lacks on this aspect, since it always assign the same role to all given identities. Obviously this choice is not applicable on real production environments. LDAP and Identity and Access Management products could be the right place where to store information about mapping between identities and roles, providing an easy way to manage this correlated information. On the other hand custom application like SAML Provider should be adapted to interact with them.

Moving further from the sample scenario to a real production environment, a Security Token Service (simply STS later) implementation could represents a right way to support Identity Federation achieving more flexibility and effectiveness.

Figure 6. An STS component within the sample scenario and the STS component
An STS component within the sample scenario and the STS component
An STS component within the sample scenario and the STS component

In a Web services ecosystem, an STS implements the WS-Trust interface and issues, exchanges and validates security tokens, acting as a trusted third party brokering trust relationships between a consumer and a provider. WS-Trust open standard defines how request and issue security tokens and how to establish trust relationship.

Although WebSphere Application Server could directly contact an Security Token Service, the Figure 6 shows how the sample scenario evolves after the STS component introduction. In this new scenario the ESB would hold the security protocol transformation management, while the STS would be responsible for supplying and forging SAML assertions, taking advantage from its integration with Identity and Access Management components.

The ESB Gateway of JHKL Inc.

In this section, as Figure 7 shows, JHKL Inc. chooses to realize the ESB Gateway using the WebSphere DataPower SOA Appliance.

Figure 7. A different approach to realize the ESB Gateway of ACME Inc.
Sample figure containing an image
Sample figure containing an image

In this case, the WebSphere DataPower has the responsibility to:

  1. Validate the digital sign of the SAML Assertion
  2. Associate a locally valid service identity to the caller's role
  3. Exchange the SAML Assertion to a different security protocol able to carry the service identity

About point 2 and 3, assuming that WebSphere DataPower has to solve these aspects itself (without contacting any external components), we chose the following methods:

  1. Use a simple XSL file to map SAML roles into locally valid service identities
  2. Generate an LTPA token at the transport level for enabling identity propagation

In the previous section, we assumed that ACME Inc. uses the WS-UNT for enabling identity propagation within its private domain, such choice represents one of the most common and interoperable method. In contrast we assumed that JHKL Inc. takes advantage of the LTPA token, that is a proprietary protocol. The JHKL Inc.’s choice relies on the premise that, considering an overall Service Oriented Architecture infrastructure, it is not always necessary to need full interoperability.

In fact, assuming that "Application B" will always be LTPA-compatible, it will be invoked by an increasing numbers of consumers and it needs to access other secured resources (like Enterprise Java Beans) within WebSphere cells, the LTPA token could be a reasonable choice, thanks to its manageability and performance characteristics. In fact, an end-to-end identity propagation that relies on a security token generation for every involved hop could be expensive, the LTPA token represents a secure way to propagate an identity, since it is encrypted, signed and provides a validity period feature also.

Implementing the ESB Gateway of JHKL Inc."

To implement the ESB gateway of JHKL Inc., a WS-Proxy object has been configured inside the DataPower and, as Figure 5 shows, our request flow contains essentially two actions:

  1. One validation action
  2. One AAA action
Figure 8. WS-Proxy request flow
WS-Proxy request flow
WS-Proxy request flow

While the validation action simply verifies the SAML Assertion signature, the AAA action makes a more complex work.

The AAA configuration

As first step, the AAA has to extract the user's identity, this is an important task within the sample scenario. In fact, the assertion's subject contains the caller's identity (for example "John Doe"), that from the JHKL Inc. perspective could be useful mainly for auditing purpose. Instead, for the authentication/authorization and identity propagation purposes we need to extract the caller's role for example "Guest"), in our scenario this information is meaningful for JHKL Inc. because had to be mapped to a local service identity. For this reason, as Figure 9 shows, we use an XPATH expression to extract the caller's role from the SAML Assertion's attribute.

Figure 9. How to extract the user's identity
How to extract the user's identity
How to extract the user's identity

At this point, we have only to exchange the caller's role with a local service identity and we use an AAA Info file to do that.

Figure 10. How to authenticate the user
How to authenticate the user
How to authenticate the user

The figure below shows the AAA Info file used for mapping roles to local service identity. Just for test purpose, the AAA Info file contains only one relationship where the role "Guest" is mapped to the identity "iod=service1,o=defaultWIMFileBasedRealm", but this file also shows how the mapping is only between a restrict number of items (all possible roles) and a restrict number of local identity (one for each authorization level). We used an AAA Info file, but the DataPower allows a great flexibility and it is possible to handle this mapping in other ways, for example querying an LDAP.

Listing 3. AAA Info file for mapping credential
<?xml version="1.0" encoding="utf-8"?>
<AAAInfo xmlns="">
  <Summary>Map abstract role to local service identity.</Summary>

With this step, we simply want to authorize all authenticated requests, that means all requests with a valid signature and a valid role (where a role is valid if the AAA Info file can map it to a local identity).

Figure 11. Authorization step
Authorization step
Authorization step

The last step implements the message transformation, here we remove the WS-Security header and generate an LTPA token (at the transport level) built on the mapped identity (the role "Guest").

Figure 12. Post processing
Post processing
Post processing

Test the sample scenario

For our test, to simulate the "Application B" we developed a simple Web Service that exposes one operation to have the current date, to simulate the "Application A" we used a generic Web Service client tool instead.

Listing 4 shows a request message from the "Application A", where we can see the WS-UNT (containing the identity of John Doe) inside the SOAP Header.

Listing 5. The initial SOAP message request.
 <wsse:Security soapenv:mustUnderstand="1" 
      <wsse:UsernameToken wsu:Id="UsernameToken-624174388" 
         <wsse:Password Type="http://...wss-username-token-profile-1.0#PasswordText">

Looking the message produced by ESB Gateway of ACME Inc. (Listing 5), our focus is on three childs of the SAML Assertion:

  • The issuer indicates ACME Inc. as owner of the Assertion
  • The subject indicates John Doe as the caller's identity
  • The attribute statement indicates that John Doe has got the "Guest" role
Listing 6. The SOAP message request after the transformation by the ESB Gateway of ACME Inc.
<soapenv:Envelope  xmlns:log=".../" xmlns:soapenv="..." xmlns:env="..." xmlns:dp="...">
      <wsse:Security xmlns:wsse="..." soapenv:mustUnderstand="1">
         <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
         ID="1" IssueInstant="2010-01-19T15:34:33.331Z" Version="2.0">
            <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
               ACME Inc.
            <ds:Signature xmlns:ds="">
             <saml:Attribute Name="Role" NameFormat="Role">
                <saml:AttributeValue xmlns:xsi="..." xmlns:xs="..." 
           <saml:AuthnStatement AuthnInstant="2010-01-19T15:34:33.331Z">

We assumed that ESB Gateway of JHKL Inc. propagate the identity toward the "Application B" using the LTPA token at transport level, for this reason, as Listing 7 shows, the request message produced by the DataPower doesn't contain any WS-Security information.

Listing 7. The SOAP request message after the transformation by the ESB Gateway of JHKL Inc.
<soapenv:Envelope xmlns:soapenv="..." xmlns:env="..." xmlns:dp="...">

Instead, figure 13 shows information about the request message that DataPower forwarded to "Application B", where you can see the LTPA cookie added by post processing action (Figure 12).

Figure 13. Headers after post processing
Headers after post processing
Headers after post processing

At the end, the listing 8 shows the response message from "Application B".

In our sample scenario, we assumed that no security information are required on response direction, but in a production environment, ACME Inc. could require a signed response message, in order to be sure about message integrity and origin.

Listing 8. The SOAP message response.
<soapenv:Envelope xmlns:soapenv="">
      <ns2:getDateResponse xmlns:ns2="">
         <return>[Tue Jan 19 16:34:33 CET 2010]</return>


This article starts from the need to support Identity Federation across enterprises (or within a single enterprise) and uses a sample application cooperation scenario to propose two possible solutions. Both solutions rely on the assumption that an Enterprise Service Bus Gateway will be used as implementation pattern, since it represents a building block for smoothly addressing these cooperation scenarios, avoiding tremendous impacts on the existing IT infrastructure and the usual internal application behavior

As a result of this assumption, two possible solutions for implementing an ESB Gateway were introduced; the former leverages the basic Websphere Application Server functions while the latter leverages Datapower built-in features. What should be clear reading the article are the difficulties that could rise while implementing described scenarios and how these could be addressed using different implementation strategies.

As we can imagine in a large scale scenario the most performing, robust and still flexible solution would be the one composed by the ESB plus a Security Token Service (STS), this broker service will issue and validate security tokens, acting as a trust authority, decoupling the authentication service from the ESB infrastructure.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=SOA and web services, WebSphere
ArticleTitle=Identity federation using SAML and WebSphere software