SOA: Managing identity contexts across service requests

Identity propagation considerations in a SOA environment

Businesses embrace Service Oriented Architecture (SOA) to help their IT meet the needs of their business. The loose coupling of services and their distributed nature across organizations and trust boundaries presents a number of challenges. When it comes to the reuse of existing applications or service connectivity across organizational or technological boundaries, the identity systems can vary and so can the credential systems. Managing, mapping, and propagating identity across these environments is necessary. This article discusses the business challenges when managing identity contexts in Web services and SOA. It outlines the importance of creating solutions based on standards. The security token service (STS) capability in IBM® Tivoli® Federated Identity Manager (TFIM) is a key building block that can be used in solutions to address these identity propagation requirements. This article explains the capabilities of the STS and outlines architectural approaches using TFIM to solve these needs.


Ann-Louise Blair (, Software Engineer, IBM Tivoli

Ann-Louise Blair is a Software Engineer in the IBM Australia Development Laboratory. She has four years experience working in the IT industry and holds a Bachelor of Software Engineering degree from the University of Queensland. Having worked in both testing and development roles in the Gold Coast Integration Factory team, Ann-Louise has gained expertise working with many Tivoli software products.

Kerry Gunn (, Staff Software Engineer, IBM

Kerry Gunn holds a B. IT. (honours) from James Cook University. Currently he is working for Tivoli Security product development organization in the Gold Coast, Australia. He has been working with Tivoli Access Manager since 2003.

08 January 2008


Businesses embrace Service Oriented Architecture (SOA) to help their IT meet their business needs. User identities and credentials can differ across organizational or technological boundaries within the SOA environment. Therefore, many identity issues arise when establishing the reuse of existing applications or services that span these boundaries. How to manage, map, and propagate identity across these environments is becoming a key consideration when designing SOA solutions.

In this article, we discuss the business challenge of identity propagation, which is being largely driven by corporate SOA efforts. We will also explain the importance of implementing a standards-based solution to address these issues. Finally, the article shows the patterns of possible approaches to achieve end-to-end identity propagation including examples of solutions that exist today.

Business challenges when managing identity contexts

Service Oriented Architecture (SOA) is an architectural style to help enhance business agility. The primary goal of SOA is to design the IT environment in such a way that it can quickly adapt to the changing needs of the business. This is achieved by creating discrete business function components, termed 'services' that can be combined to implement business processes. Identity needs to flow freely between these disparate services, regardless of their underlying technology. The loose coupling of services and applications and their possible operations across organizations and trust boundaries creates identity propagation challenges.

Identity challenges in Web services and SOA

The following points outline some of the issues pertaining to identity propagation in Web-services and SOA:

  • Increasing heterogeneous user base. It is difficult to manage the wide variety and vast number of consumers for the available services. Consumers can include business partners, customers and contractors. Appropriate access controls for each user must be maintained.
  • Multiple, diverse enforcement points. The myriad of enforcement points can include XML gateways, application servers, enterprise service buses and mainframes. Maintaining the necessary enforcements requires application coding which is expensive to maintain and support.
  • Compliance concerns. To meet compliance regulations, it is important to accurately maintain the user repositories in mainframes and lines of business. The identities need to flow from the gateway to the mainframe.

Challenges around identity propagation

A Service Oriented Architecture provides services that can be interconnected and reused when required to fulfill a particular business process. It is imperative that these services are connected and implemented in a secure and auditable manner, according to a defined security policy. Identity therefore plays an integral role in delivering on the promise of service orientation.

The following three identity propagation key challenges have been identified

  1. There are many notions of user identity.
    On average, large corporations can be expected to maintain over one hundred user repositories. This situation is complicated further through integration with external applications and services and the potential for changes in business process and service implementations.
  2. How to pass user identity
    The different underlying technologies across technological boundaries, both inside and outside a single organization, require different ways of passing user identity. For example, passing a user identity to IBM RACF® is very different to passing a user identity to Microsoft®.NET. The options and formats available for propagating a user's identity between services will depend on the individual service implementations. The infrastructure should therefore include identity services to deal with these identity mediation issues, so that services can be easily interconnected without worrying about how to map and propagate user identity from one service to the next. This approach greatly reduces the amount of code required and hence improves the speed and ease of developing new services.
  3. Identity flow is not business logic
    In order to realize the business benefits from SOA, the services should only contain business logic. Any other infrastructure issues should be dealt with by SOA middleware. Attempting to add non-business logic to services makes them much more difficult to change and much more fragile in the event of change. User identity is a key technical issue that should be dealt with by the SOA middleware. This includes what user identity is passed to the next service and how the user identity is passed to the next service.

Standards-based solution

SOA environments comprise loosely coupled services operating across a distributed network. The heterogeneous nature of these environments introduces many challenges in designing identity propagation solutions. As well as adhering to the principles of SOA itself, identity propagation solutions designed for these SOA environments must:

  • Be capable of understanding and operating with a variety of formats for representing identity
  • Have the ability to translate between different identities
  • Be able to provide maximum interoperability with the platforms and systems on which the SOA solutions are deployed

Solutions based on open standards are advisable to ensure that these interoperability requirements are effectively met.

WS Trust Standard

IBM's SOA identity propagation solution is built on the WS-Trust open standard detailed at This standard is part of the WS-Security family of standards and is the open mechanism by which:

  • Security tokens can be validated, issued, and renewed
  • Trust relationships can be established, assessed and brokered

A Security Token Service (STS) is a Web service that implements the WS-Trust interface.

TFIM overview

Tivoli Federated Identity Manager (TFIM) is an IBM product that provides identity and access security services in a SOA or Web services environment. The focus points of the product are:

  • Federated single sign-on
  • Identity token service

High level operation of solution

The STS is a component of the TFIM product, which plays an integral part in the IBM SOA identity propagation solution. Figure 1 shows the interaction between a WS-Trust client and the TFIM STS.

Figure 1. WS-Trust token request
Basic Flow

The Security Token Service is accessible by WS-Trust clients and provides a means by which identity tokens can be validated and exchanged for different token types or values. The actual task that is performed by the STS is dependent upon its configured set of trust module chains and the contents of the request.

Each WS-Trust service request is expected to include three parameter values to specify which particular trust module chain will process the request. These three request parameters, referred to as AppliesTo, Issuer and Token Type, are matched with the corresponding configuration properties of each trust chain. Use of these parameters is described in Table 1.

Table 1. WS-Trust service request parameters
AppliesToA representation of which service the WS-Trust relates to, or for what scope the requested security token is required. Typically in URL format and can be specified as a regular expression, for example,
IssuerThe entity or type of service component that is issuing the WS-Trust request. Typically in urn format, for example, urn:itfim:wesb
Token typeURI describing the type of token requested in the response to the WS-Trust request, for example,

A trust module chain consists of a sequence of module instances. Data from the WS-Trust request is stored in an XML document called the STS Universal User (STSUUSER). The STSUUSER document is then passed between modules in the trust module chain. The modules transform the data. At the completion of this process, the transformed data from the STSUUSER document is returned to the client as the WS-Trust response.

Module instances can be configured in several different modes to suit the business requirements. These modes include validate, map, issue and other. Modules in validate mode are responsible for validating the authenticity of identity tokens. Those in map mode transform the data that passes through the trust module chain, for example, using XSL transforms. Meanwhile, modules that are in issue mode will generate identity tokens from the data that passes through the trust module chain. 'Other' is a general processing mode, for example, to perform authorization. A minimally configured trust module chain will likely have modules configured in validate, map, and issue modes. An authorization module may optionally be inserted before or after the map module. Figure 1 above shows a trust module chain with the validate,, authorize, map, issue modules. Multiple map modules can also be required in cases where data for the identity mapping process needs to be retrieved from multiple data sources.

The TFIM STS supports a variety of identity token types including:

  • Username
  • SAML assertion (versions 1.0, 1.1 and 2.0)
  • RACF PassTickets
  • LTPA
  • Kerberos
  • X.509 certificate

For a complete list of the supported token types please refer to the Tivoli Federated Identity Manager 6.1.1 Configuration Guide

If you require a token type which is not currently available, an additional token module can be coded using Java™ technology. Modules that represent an identity token type are typically configured in validate or issue mode.

WS-Trust client integrations

A number of WS-Trust client integrations currently exist that can utilize the TFIM STS. This list includes, but is not limited to:

  • IBM WebSphere® Enterprise Service Bus (WESB) has a token mediation primitive that calls a WS-Trust client that is a common component.
  • WebSphere Message Broker (WMB) has a custom node that calls a WS-Trust client that is a common component.
  • DataPower appliance has an embedded WS-Trust client that allows it to call out to the STS.
  • WebSphere Application Server (WAS) uses the Web Service Security Management (WSSM) is a token generator and token consumer to allow WAS to call out to the STS.
  • TFIM JAAS Login Module is called by a JCA adapter for legacy and mainframe applications. It in turn calls a WS-Trust client that is a common component.

Identity propagation patterns

There are three main design patterns used when integrating with the SOA Identity Propagation solution:

  • Service Requester
  • Service Provider
  • Intermediary

Service Requester pattern

The Service Requester pattern recognizes the need for consumers of a service to provide the service with “what it expects”. In this pattern, an identity token is used to represent the authenticated identity in the service component. The STS is used to transform the authenticated identity to a token that is suitable for sending in the service request, as shown in Figure 2.

Figure 2. Service Requester pattern
Basic Flow

Later in this article, the TFIM Web Services Security Management (WSSM) Token Generator component and the WS-Trust aware JAAS login module are discussed. These are examples of how the service requester pattern can be applied.

Service Provider pattern

In the Service Provider pattern shown in Figure 3, an incoming identity token is sent to the STS for validation and mapping to a local identity. This pattern is used in cases where the receiving service component is expected to accept an identity token that it is not able to natively support. The motivation for this might be that an enterprise-wide token standard has been employed or that the validation capabilities of the service component are insufficient for the requirements of the particular SOA environment.

Figure 3. Service Provider pattern
Basic Flow

An example of this pattern is the TFIM WSSM Token Consumer component discussed later in this article.

Intermediary pattern

The Intermediary pattern enables identity propagation through an intermediary, such as an enterprise service bus. This pattern is a combination of the service requester and service provider patterns, where incoming identity tokens need to be validated (as in the service provider pattern) before the identity token for an outgoing request is generated (as in the service requester pattern). ESBs are required to perform identity mediation, because they often sit at the boundary of different administrative domains. This pattern is depicted in Figure 4.

Figure 4. Intermediary pattern using an ESB
Basic Flow

Examples of this pattern include the TFIM integration with:

  • WebSphere Enterprise Service Bus
  • WebSphere Message Broker
  • WebSphere DataPower XS40 and XI50 appliances

Cross domain Web services

There is often a need for cross domain communication between applications. An identity propagation problem arises because many of these domains are heterogeneous and their identities and representation of these identities are different.

An example of the problem is that a user is authenticated in domain A and there is a need to make a call to an application in domain B. There is a requirement for the identity to be transmitted from domain A to domain B and mapped from the domain A format to the domain B format.

Figure 5. Cross domain TFIM solution
Cross Domain 3

Figure 5 shows an example solution to the problem using TFIM. The TFIM STS is used for validation, mapping and exchange of identities and tokens and WSSM is used as the WS-Trust client that allows WAS to make calls to the TFIM STS.

The flow is as follows:

  1. WAS Cell A makes a call to a trust service to exchange the user ID John Doe for a format that can be transmitted to and consumed by WAS Cell B.
  2. The trust service creates a SAML assertion representing the original user ID.
  3. The SAML assertion is transmitted as part of a Web services call to WAS Cell B.
  4. WAS Cell B makes a call to a trust service to exchange the SAML assertion for an identity and format that it can consume.
  5. The trust service creates a new token and maps the original identity for a WAS Cell B identity.

Accessing existing systems

Another common scenario is the need to incorporate existing systems into new SOA deployments. These systems have been deployed and running successfully in customer environments and there is no need to remove them. It is possible to simply have all authenticated users mapped to a single identity at the legacy application, but for fine grained authorization and audit reasons, it is preferred to propagate the original identity through to the legacy application in some form.

The problem is similar to the cross domain scenario, there is a user authenticated to application A and there is a need to make a call to the legacy system which requires a different identity and format.

Figure 6. Existing system TFIM solution
Legacy 3

Figure 6 shows an example TFIM solution to this problem. A WAS J2EE™ application needs to make a call to a CICS® application.

The flow is as follows:

  1. The WAS J2EE application calls the JCA configured TFIM login module, (a WS-Trust client that allows JCA to make a call to the TFIM STS), to exchange the JAAS Subject identity for a RACF passticket that can be used to access the CICS application. (Note: A RACF passticket is a programmatic generated password representation that can be used in place of a real password. It has a short lifespan and can be used only one time.)
  2. The trust service generates a RACF passticket and returns it to the TFIM Login Module.
  3. This RACF passticket is used to access the CICS application.

Enterprise Service Bus

The Enterprise Service Bus, or ESB, is an important building block for SOA. It provides a simple mechanism to allow access to services via a known, standard method. When an ESB is used in a Web services environment, it is able to perform identity operations. These operations include:

  • Authentication
  • Identity and attribute mapping
  • Token issuance
  • Authorization
  • Auditing

What this means is that the identity operations can be abstracted from the Web service endpoints and the ESB can do some or all of the work needed to ensure an identity is made available to the Web service in the desired format.

An example of the problem is when Service A makes a call out to Service B via an ESB, but the identity needs to be mapped from the format that already exists to the format that Service B expects.

Figure 7. ESB TFIM Solution

Figure 7 shows an example TFIM solution to this problem. It is similar to the example in the cross domain Web services section (Figure 3) except that portal server doesn't call the Web service directly but rather uses WebSphere ESB (WESB). The additional flow is as follows:

  1. WAS cell A makes a call to WESB passing the identity in a SAML 1.0 assertion.
  2. The call is mapped and passed to an identity mediation in WESB.
  3. The identity mediation is configured to map the incoming SAML 1.0 assertion to an LTPA token using the TFIM STS.
  4. WESB forwards the call onto the target service passing the identity in the required LTPA token format.

End-to-end identity propagation

Whilst the previous scenarios have shown how the TFIM STS can be used to solve a single problem it is more useful to show that it can be used to provide a solution for a complete end to end scenario. The following example shows this scenario and the TFIM STS solution.

Figure 8. End-to-end solution
End to End

Figure 8 shows the basic problem. A requestor needs to be able to single sign-on and make a request to a Domain A legacy application. To enable this to happen, a number of things are required:

  • The requestor provides an authenticated token (SAML 1.0)
  • This token needs to used to provide single sign on to Domain A (LTPA)
  • The identity assertion must be converted to an identity that exists at the legacy application (RACF Passticket)

The first requirement is to add a mechanism to convert the SAML 1.0 identity to a Domain A LTPA identity. This can be achieved as above in either the cross domain or ESB scenario. Next, a mechanism is added that exchanges the Domain A LTPA identity for a RACF Passticket that can be consumed by the legacy application. This can be achieved as above in the accessing existing legacy applications section.

Figure 8 shows the complete solution for the scenario using TFIM STS.

What the above example indicates is that in a complete solution the TFIM STS can and should be used at multiple points in the solution architecture.


SOA has become a critical part of today's corporate world. Users often have multiple identities and credentials across the heterogeneous systems in a SOA environment. As a result, it is extremely important for these identities to be managed, mapped, and propagated successfully across the environmental boundaries.

In this article, the key features of end-to-end identity propagation solutions were discussed. The implemented solutions should be externalized from the individual applications within the SOA environment. As such the solutions should be capable of understanding and translating a wide variety of formats for representing identity and propagating them across different platforms and systems within the SOA environment. In order to meet these interoperability requirements, the solutions should be based on open standards. Several patterns have been developed to assist with designing these solutions.

IBM's SOA identity propagation solution is built on the WS-Trust open standard. It uses the Tivoli Federated Identity Manager (TFIM) STS as a key component. TFIM provides identity and access security services in a SOA or Web services environment. It offers federated single sign-on and an identity token service. This article describes how TFIM can play an integral part in end-to-end identity propagation solutions in a SOA environment.


The authors would like to thank Sridhar Muppidi and Neil Readshaw for their contribution to the content of this article and for the time they took to review the article and to offer us guidance.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Tivoli (service management) on developerWorks

Zone=Tivoli (service management), Security, Tivoli
ArticleTitle=SOA: Managing identity contexts across service requests