Configure secure communications with WebSphere Application Server and WebSphere Message Broker using SAML 2.0 tokens and Tivoli Federated Identity Manager

This article shows you how to configure secure communication using the SAML token profile with WebSphere Application Server V7 hosting a Web service client and server, and WebSphere Message Broker V7 acting as an enterprise service bus to mediate the application communication and ensure that security requirements are met. IBM Tivoli Federated Identity Manager V6.2 acts as the Security Token Service (STS) and issues the SAML tokens.

Share:

Rashmi Katagall (rashmikatagall@in.ibm.com), Software Engineer, WebSphere Message Broker Development Team, IBM

Photo of Rashmi KatagallRashmi Katagall is a Software Engineer on the WebSphere Message Broker Development Team in India. She is a graduate from KLS Gogte Institute of Technology in Belgaum, India, and has been working for IBM for three years. You can contact Rashmi at rashmikatagall@in.ibm.com.



13 April 2011

Introduction

Security Assertion Markup Language (SAML), developed by the Security Services Technical Committee (SSTC) of the standards organization OASIS, offers a promising solution for Web single sign-on (SSO); it also has potential for use in authentication and authorization of end-to-end business processes spanning multiple systems. In SSO, the user can access multiple Web applications without having to re-authenticate on each of them. A SAML token is issued to the client by a Security Token Service (STS), with which the provider of Web applications has a trust relationship.

This article shows you how to configure secure communication using the SAML token profile with IBM® WebSphere® Application Server V7 (hereafter referred to as Application Server) hosting a Web service client and server, and WebSphere Message Broker V7 (hereafter referred to as Message Broker) acting as an enterprise service bus to mediate the application communication and ensure that security requirements are met. Both Message Broker and Application Server use IBM Tivoli® Federated Identity Manager V6.2 (hereafter referred to as Identity Manager) as the STS.

Application Server introduced support for SAML security tokens in V7 Fix Pack 7, and Message Broker introduced the SAML pass-through feature in V7 Fix Pack 1. This article shows you how to configure policy sets and bindings for signed and unsigned SAML 2.0 tokens with the bearer subject confirmation method. You'll also see how to develop appropriate trust chains on a Security Token Service (STS) to issue SAML tokens with the bearer subject confirmation method, using the STS. The communication between the client and the STS takes place over Secure Socket Layer (SSL), and you'll see how to configure this as well. Once you've walked through these steps, you'll be prepared to use applications secured with the SAML 2.0 profile.

Before you begin with the configuration, you should understand how a SAML token flows from the STS to the Web service client and provider, as shown in Figure 1. The client and provider can be developed on either Application Server or Message Broker.

Figure 1. Flow of a SAML token from the STS to the Web service client and provider
Diagram showing the flow of a SAML token from the STS to the Web service client and provider

As shown in Figure 1, the client sends a WS-Trust request to the STS to issue the SAML token. The client then sends the Web service request to the provider on Application Server or Message Broker, along with the SAML token it received from the STS. On Application Server, the provider validates information in the SAML token, such as the expiration time, signature, and so on, before it processes its business logic. On Message Broker, the provider makes a call to the STS to validate the SAML token, as it cannot perform the validation itself. The SAML token always flows one way, from client to provider. In order for these communication flows to work properly, you need to configure the various components of the system shown in Figure 1. The following sections show you how to do that.

Configuring communication between Application Server and the STS

To begin, you need to configure communication between Application Server and the STS so that the STS issues a security token. First, you need to set up the policy sets and bindings, and set up SSL communication.

  1. On the Application Server console, navigate to Services => Policy sets => Application policy sets.
  2. Select Username WSHTTPS default and click Copy.
  3. Enter a unique name -- SampleUsernameWSHTTPS, for this example -- and click OK.
  4. Click SampleUsernameWSHTTPS => WS-Security => Main policy.
  5. Figure 2 shows the dialog for message security policies that you'll see next. Uncheck Message level protection and click Apply:
    Figure 2. Establishing message security policies
    Screenshot showing how to establish message security policies
  6. Save the changes by clicking Save.
  7. On the Application Server console, navigate to Applications => Application Types => WebSphere enterprise applications => your_application_deployed => Service client policy sets and bindings. Figure 3 shows the window for configuring properties on the deployed application, with the appropriate link highlighted:
    Figure 3. Configuring Web service properties
    Screenshot showing how to configure Web service properties
  8. Check the box corresponding to your application service.
  9. From the Attach Client Policy Set drop-down menu, choose SampleUsernameWSHTTPS.
  10. Check the box corresponding to your application service.
  11. From the Assign Binding drop-down menu, choose New Application Specific Binding, as shown in Figure 4:
    Figure 4. Selecting an application-specific binding
    Screenshot showing how to select an application-specific binding
  12. Your screen should now look like Figure 5 below, where you can configure application-specific binding properties. Enter an appropriate name under Bindings and configuration name, such as NewHttpS.
  13. Select WS-Security from the Add drop-down menu.
    Figure 5. Configuring application-specific binding policies
    Screenshot showing how to configure application-specific binding policies
  14. Click Authentication and protection and then select Authentication tokens => request:uname_token, as shown in Figure 6:
    Figure 6. Configuring a token on an application-specific binding
    Screenshot showing how to configure a token on an application-specific binding
  15. You'll see the screen shown in Figure 7, with the important information filled in for you. Click Apply and then click Callback handler.
    Figure 7. Token generator
    Screenshot showing the token generator
  16. Figure 8 shows the next screen. Enter the username and password to authenticate with the STS that you'll be using.
  17. Click OK and then click Save:
    Figure 8. Completing the steps for application-specific binding
    Screenshot showing how to completing the steps for application-specific binding
  18. Navigate to Security => SSL certificate and key management => Manage endpoint security configurations => node endpoint (or server endpoint).
  19. Click Key stores and certificates and then click NodeDefaultTrustStore, as shown in Figure 9:
    Figure 9. Selecting a trust store for keystores and certificates
    Screenshot showing how to select a trust store for keystores and certificates
  20. You should now see the window for retrieving the signed certificates from Identity Manager, as shown in Figure 10. Click Sign certificates and then click Retrieve from port.
  21. Enter the appropriate host, port, and alias name, and then click Retrieve Signer Information.
  22. Click Apply and Save.
    Figure 10. Retrieving the signer certificate from Identity Manager
    Screenshot showing how to retrieve the signer certificate from Identity Manager
  23. Navigate to Applications => Application Types => WebSphere enterprise applications => your_application_deployed => Service client policy sets and bindings.
  24. Check the box corresponding to the service and click Detach Client Policy Set.

Configuring communication between the client and Web service on Application Server

You'll need to create proper policy sets and bindings in order to implement SAML-secured communications between your client and your Web service. The client and the service will have the same policy set, whereas the bindings for the two will be different. Begin by creating the SAML 2.0 policy sets:

  1. On the Application Server console, navigate to Services => Policy sets => Application policy sets.
  2. Select SAML20 Bearer WSSecurity default and click Copy.
  3. Enter a unique name -- SAML20BearerPolicySet, for this example -- and click OK.
  4. Click SAML20BearerPolicySet => WS-Security => Main policy.
  5. Uncheck Message Level Protection and click Apply.
  6. Save the changes.

Next, you need to create SAML 2.0 policy set bindings for the client.

  1. On the Application Server console, navigate to Services => Policy sets => General client policy set bindings.
  2. Select SAML Bearer Client Sample and click Copy.
  3. Enter a unique name -- SAML20BearerClientBinding in this example -- and click OK.
  4. Click Saml20BearerHttpSClientPSB => WS-Security => Authentication and protection.
  5. Under Authentication Tokens, click gen_saml20token.
  6. Click Callback handler.
  7. Under Basic Authentication, enter the authentication details to communicate with STS.
  8. Under Custom Properties, edit:
    • stsURI to point to the full path of the STS host. If you don't need to configure SSL, stsURI should point to a non-SSL port such as http://<stshost>:9080/.....
    • wstrustClientPolicy and wstrustClientBinding to point to the policy set and binding you created earlier for communication with the STS.
  9. Click Apply and then Save Your screen should look like Figure 11:
    Figure 11. Configuring the callback handler of gen_saml20token
    Screenshot showing how to configure the callback handler of gen_saml20token

Now you need create more SAML 2.0 policy set bindings, this time for the Web service.

  1. On the Application Server console, navigate to Services => Policy sets => General provider policy set bindings.
  2. Select SAML Bearer Provider Sample and click Copy.
  3. Enter a unique name -- SAML20BearerProviderBinding, for this example -- and click OK.
  4. Click SAML20BearerProviderBinding => WS-Security => Authentication and protection.
  5. Click con_saml20token under Authentication Tokens.
  6. Click Callback handler.
  7. You need to establish what to do in case an unsigned SAML 2.0 token is encountered:
    • Delete trustStoreType, trustStorePassword, and trustStorePath.
    • Click New and enter signatureRequired for Name and false for Value.
    • Click New and enter trustedAlias for Name and sts_alias for Value.

    You should end up with a screen like Figure 12:

    Figure 12. Configuring the callback handler for con_saml20token to handle an unsigned SAML token
    Screenshot showing how to configure the callback handler for con_saml20token to handle an unsigned SAML token
  8. Next, set the configuration for handling a signed SAML 2.0 token. But first, you need to have already generated a keystore with a signer certificate. The keystore password used in this example is keystorepass and the keystore is dsig_sts.jks. For these attributes, trustStoreType to jks, trustStorePassword to keystorepass, and trustStorePath to ${USER_INSTALL_ROOT}/etc/dsig_sts.jks, as shown in Figure 13 (though you should obviously change these attributes to suit your requirements). Copy the keystore to the appropriate location if it's not there already.
    Figure 13. Configuring the callback handler for con_saml20token to handle signed SAML tokens
    Screenshot showing how to configure the callback handler for con_saml20token to handle signed SAML tokens
  9. Click Apply and then Save.

The policy sets and bindings have now been configured. Apply these to the client and service. Now, as you invoke the client, a WS-Trust request is sent to the STS asking it to issue the SAML 2.0 token. This request is shown in Listing 1.

Listing 1. WS-Trust request message from the client to the STS
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
    <soapenv:Header>
       <wsa:To xmlns:wsa="http://www.w3.org/2005/08/addressing">
            https://HostnameForSTS:9443/TrustServerWST13/services/RequestSecurityToken
       </wsa:To>
       <wsa:MessageID xmlns:wsa="http://www.w3.org/2005/08/addressing">
            urn:uuid:F81EA90D3F125892041274943526169
       </wsa:MessageID>
       <wsa:Action xmlns:wsa="http://www.w3.org/2005/08/addressing">
            http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue
       </wsa:Action>
    </soapenv:Header>
    <soapenv:Body>
       <wst:RequstSecurityToken 
       xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
            <wst:TokenType> 
                  http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAML2.0
            </wst:TokenType> 
            <wst:RequestType> 
                  http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
            </wst:RequestType> 
            <wst:KeyType> 
                  http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer
            </wst:KeyType>
            <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
                <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
                    <wsa:Address>
                        http://localhost:9080/MyService/HelloService
                    </wsa:Address>
                </wsa:EndpointReference>
            </wsp:AppliesTo>
     </wst:RequstSecurityToken >
   </soapenv:Body>
</soapenv:Envelope>

Configuring a trust chain on Identity Manager

Identity Manager uses the RequestType, AppliesTo, and TokenType attributes of the WS-Trust request message to map an incoming request to the appropriate trust chain. In the WS-Trust request message in Listing 1, these attributes have the following values:

  • RequestType: http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
  • AppliesTo: http://localhost:9080/MyService/HelloService
  • TokenType: http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0

Now you need to create a trust chain on Identity Manager.

  1. On the Identity Manager console, navigate to Tivoli Federated Identity Manager => Configure Trust Service => Trust Service Chains.
  2. Click Create and then click Next.
  3. You should see a window like the one in Figure 14. Give an appropriate name to the chain -- Issue SAML2.0 for WAS Service in this example -- and click Next.
    Figure 14. Creating a chain
    Screenshot showing how to create a chain
  4. Now select Issue Oasis URI in the Request Type drop-down menu. Enter the URL above for AppliesTo and select SAML2.0 from the Token Type drop-down menu. Your screen should look like Figure 15. Click Next and then Next again.
    Figure 15. Configuring the trust chain with specific attributes
    Screenshot showing how to configure the trust chain with specific attributes
    Keep in mind that Application Server does not send an issuer in its WS-Trust Request message. Therefore the Issuer field on Identity Manager needs to be kept blank and any entry in this field will cause a null pointer exception. Regular expressions can be used in these fields. For instance, for Address, you could have entered REGEXP:(http://.*:.*/MyService/HelloService). The asterisk is a wild card.
  5. Now, select Default Map Module for the Module Instance and map for the Mode, then select Add selected module instance to chain, as shown in Figure 16.
    Figure 16. Selecting the module instances for the trust chain
    Screenshot showing how to select the module instances for the trust chain

    To issue a SAML 2.0 token, proper mapping is necessary. The mapping file defines the confirmation method, authentication statements, and so on that will be included in the SAML 2.0 token that is issued. Listing 2 shows the sample mapping file for the SAML 2.0 token in our example system.

    Listing 2. Sample mapping file
    <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
            xmlns:stsuuser="urn:ibm:names:ITFIM:1.0:stsuuser" version="1.0">
        <xsl:strip-space elements="*" />
       <xsl:output method="xml" version="1.0" encoding="utf-8" indent="yes" />
        <!-- Start with a copy of the document -->
          <xsl:template match="@* | node()">
            <xsl:copy>
               <xsl:apply-templates select="@* | node()" />
            </xsl:copy>
          </xsl:template>
          <xsl:template match="//stsuuser:AttributeList"></xsl:template>
          <xsl:template match="//stsuuser:Principal">
            <stsuuser:Principal>
               <stsuuser:Attribute name="name">
                  <stsuuser:Value>WAS</stsuuser:Value>
               </stsuuser:Attribute>
            <stsuuser:Attribute name="SamlSubjectConfirmationMethod"
                    type="urn:oasis:names:tc:SAML:2.0:assertion">
                <stsuuser:Value>urn:oasis:names:tc:SAML:2.0:cm:bearer</stsuuser:Value>
            </stsuuser:Attribute>
            <stsuuser:Attribute name="Issuer"
                    type="urn:oasis:names:tc:SAML:2.0:assertion">
                <stsuuser:Value>UsernamePasswordToSAML</stsuuser:Value>
            </stsuuser:Attribute>
           </stsuuser:Principal>
        </xsl:template>
    </xsl:stylesheet>
  6. Next, select Default SAML2.0 Token from the Module Instance drop-down menu and issue from the Mode drop-down menu. Click Add selected module instance to chain. Your screen should look like Figure 17. Click Next.
    Figure 17. Adding two module instances
    Screenshot showing how to add two module instances
  7. A warning may be thrown at this point. If this happens, click Continue and then Next.
  8. Now you will be prompted to select the mapping file. Copy and paste the code in Listing 2 to a text editor and save it as a file with an .xsl extension. Select the location of this file and click Next.
  9. You should now see the window shown in Figure 18. Enter a name for the issuing organization -- you can use anything specific to the STS you're using -- and change the time period for which the SAML token will be valid, if necessary:
    Figure 18. Configuring SAML properties
    Screenshot showing how to configure SAML properties
  10. On the same page (in the portion shown in Figure 19) check the Sign SAML Assertions box if you are using a signed SAML token. Select the keystore from the Keystore drop-down menu. Enter the keystore password and select List Keys; then select the key from the list. Click Next:
    Figure 19. Configuring a signed SAML token
    Screenshot showing how to configure a signed SAML token
    You will now be sent to a summary page, where you can verify the options you selected. Click Finish.
  11. The keystore must now be imported into Identity Manager: Navigate to Tivoli Federated Identity Manager => Configure Key Service => Keystores. Click Import and select the properties as shown in Figure 20.
    Figure 20. Importing the keystore
    Screenshot showing how to import the keystore
  12. The chain you just created will now be listed under Console => Configure Trust Service => Trust Service Chains. To check or alter the properties, select the chain and click on the properties.

At this point, you've finished the trust chain. Now, the STS responds to the client with a SAML 2.0 token in the wsse headers of the SOAP response message, shown in Listing 3:

Listing 3. wsse headers of the SOAP response
<wsse:Security xmlns:wsse=
   "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" 
      soapenv:mustunderstand="1">
        <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
               xmlns:xs="http://www.w3.org/2001/XMLSchema" 
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               ID="Assertion-uuiddee4b651-0128-1af0--9afe9-b4f4978a7ee1" 
               IssueInstant="2010-05-28T12:30:50Z" 
               Version="2.0">
            <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
               UsernamePasswordToSAML2.0
            </saml:Issuer>
            <saml:Subject>
               <saml:NameID>WAS</saml:NameID>
               <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
               </saml:SubjectConfirmation>
            </saml:Subject>
            <saml:Conditions NotBefore="2010-05-28T12:20:50Z" 
            NotOnOrAfter="2010-05-29T12:20:50Z">
                <saml:AudienceRestriction>
                <saml:Audience>http://localhost:9080/MyService/HelloService
                </saml:Audience>
                </saml:AudienceRestriction>
            </saml:Conditions>
            <saml:AuthnStatement AuthnInstant="2010-05-28T12:20:50Z">
                <saml:AuthnContext>
                <saml:AuthnContextClassRef>
                   urn:oasis:names:tc:SAML:2.0:ac:classes:Password
                </saml:AuthnContextClassRef>
                </saml:AuthnContext>
            </saml:AuthnStatement>
       </saml:Assertion>
   </wsse:Security>

Your client will embed this SAML 2.0 token in the wsse header of the SOAP request that it sends to the Web service. At the service, the SAML 2.0 token is validated and the response is sent back to the client. You've now seen how to secure communication between a client and a Web service on Application Server using Identity Manager as the STS. Next, you'll learn how to configure the policy sets and bindings for a Web service client and server on Message Broker.

Configuring policy sets and bindings for Web services

Web services in Message Broker are developed using SOAP nodes. Message Broker V7 with Fix Pack 1 supports the SAML pass-through feature for SOAP nodes; in other words, when a Web service provider (a flow with a SOAPInput node at the start) is developed, the SOAPInput node accepts the SAML 2.0 token in the incoming SOAP request message. It can validate the token with the external STS, or it can just let the token propagate down the flow. Similarly, in the Web service consumer (a flow with a SOAPRequest or AsyncRequest node), the SOAPRequest or AsyncRequest node can propagate the SAML 2.0 token in the outbound SOAP request message. As Message Broker offers SAML pass-through, signed and unsigned SAML tokens are handled similarly; no extra setup needs to be done in either case.

In this section, you will learn how to create the policy sets and bindings that are applied to the SOAP nodes and the security profiles. The examples you'll see here include sample flows for both scenarios. Begin by creating policy sets for the SAML 2.0 pass-through.

  1. Open Message Broker Explorer, right-click on the broker, and select Properties => Security => Policy Sets.
  2. Select Policy Sets and click Add.
  3. Give the policy set an appropriate name -- SAMLPolicySet in this example -- and click Rename.
  4. Navigate to SAMLPolicySet => WS-Security => Authentication Tokens.
  5. Your screen should look like Figure 21. Under Other authentication tokens, click Add and give a token name -- SAML20, in this example. Then select SAMLv2.0Passthrough from the Token Type drop-down menu and click Finish:
    Figure 21. Creating a SAML 2.0 policy set on a message broker
    Screenshot showing how to create a SAML 2.0 policy set on a message broker

Next, you'll create SAML 2.0 policy set bindings for the Web service consumer (the SOAPRequest node in the flow).

  1. Open Message Broker Explorer, right-click the broker, and select Properties => Security => Policy Sets. You should see the window shown in Figure 22.
  2. Select Policy Set Bindings and click Add.
  3. Select an appropriate name -- SAMLPolicySetBindingsC in this example -- and click Rename.
  4. Select SAMLPolicySet from the Associated Policy Set drop-down menu.
  5. Select the Consumer radio button for the binding configuration and then click Finish:
    Figure 22. Creating SAML 2.0 policy set bindings on the message broker
    Screenshot showing how to create SAML 2.0 policy set bindings on the message broker

Now you need to create SAML 2.0 policy set bindings for the Web service provider.

  1. Open Message Broker Explorer, right-click on the broker, and select Properties => Security => Policy Sets.
  2. Select Policy Set Bindings and click Add.
  3. Enter an appropriate name -- SAMLPolicySetBindingsP in this example -- and click Rename.
  4. Select SAMLPolicySet from the Associated Policy Set drop-down menu.
  5. Select the Provider radio box for the binding configuration and click Finish.

The policy sets and bindings are now ready. These can be applied to the SOAPInput and SOAPRequest nodes appropriately on the BAR files before you deploy them on the broker. To create policy sets for SAML 1.1, select SAMLv1.1 Passthrough from the Token Type drop-down under Other authentication tokens.

Now you're ready to create a security profile for SAML 2.0 validation using the STS.

  1. Open Message Broker Explorer, right-click the broker, and select Properties => Security => Security Profiles.
  2. Your screen should look like Figure 23 below. Select Security Profiles and click Add. Press F2 to rename this profile ValidateSAML20.
  3. Select WS-Trust v1.3 STS from the Authentication drop-down menu.
  4. Enter an appropriate STS URL for authentication configuration and click Finish:
    Figure 23. Creating a security profile on a message broker for authentication
    Screenshot showing how to create a security profile on a message broker for authentication

Finally, you'll need to create a security profile for issuing SAML 2.0 tokens with Identity Manager as the STS.

  1. Open Message Broker Explorer, right-click on the broker, and select Properties => Security => Security Profiles.
  2. Select Security Profiles and click Add. Press F2 to rename the profile IssueSAML20.
  3. Select WS-Trust v1.3 STS from the Mapping drop-down menu.
  4. Enter an appropriate STS URL for the mapping configuration and click Finish.

You can now apply these security profiles to the SOAPInput node on the BAR file before deploying them on the broker.

Configuring a trust chain on Identity Manager to issue SAML 2.0 tokens for Message Broker

A Web service client developed on Message Broker will have a SOAPRequest node for making requests to the Web service. The SOAPRequest node in Message Broker V7.0.0.1 can call the Web service with a SAML token; thus, you should make a SAML token available to it, which you can do using an MQInput, HTTPInput, or SecurityPEP node. SecurityPEP is a new type of node in Message Broker 7.0.0.1, so the steps to configure it to issue SAML 2.0 tokens are explained here.

You'll need to create a message flow to serve as a Web service client, as shown in Figure 24, and set the properties on the SecurityPEP node accordingly. Figure 24 shows the Web service client flow on the message broker and the SecurityPEP node properties:

Figure 24. Web service client flow
Screenshot showing Web service client flow

The flow is invoked by an HTTP client sending a message like the one in Listing 4. Fill in the username and password as appropriate for your setup.

Listing 4. Invoking the flow
<Sample>
<Username>dummyuser</Username>
<Password>dummypasswd</Password>
<IssuedBy>dummyissue</IssuedBy>
</Sample>

Create a BAR file using the above flow and set its properties as follows:

  • For SecurityPEP properties, set securityProfileName to IssueSAML20.
  • For the SOAPRequest node, set Policy Set to SAMLPolicySet, set the Policy Set Binding to SAMLPolicySetBindingC, and set the Security profile to Default Propagation, as shown in Figure 25:
Figure 25. Setting the properties of the SOAPRequest node
Screenshot showing how to set the properties of the SOAPRequest node

Next, create a message flow that is a Web service and set the properties on the SOAPInput node of the BAR file, using the values in Figure 26:

Figure 26. Setting the properties of the SOAPInput node
Screenshot showing how to set the properties of the SOAPInput node

Now the message flows, along with their associated policy sets and bindings, are ready to be deployed on Message Broker.

Configuring trust chains on Identity Manager to issue and validate SAML 2.0 tokens

When the Web service client is invoked, the SecurityPEP node makes a WS-Trust request to Identity Manager with the following attributes:

  • RequestType: http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
  • AppliesTo: urn:<BrokerName>.<EGName>.<MessageFlowName>
  • Issuer: dummyissue (you can also set this to REGEXP:(.*) to accept any issuer)
  • TokenType: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken

AppliesTo would be wmq:/msg/queue/<inputqueue>@<queuemanager> if you are using an MQInput node, and http://localhost:7080/<url-on-HttpInput-Node> if you are using an HTTPInput node. Using these attributes, you can create the chain to issue SAML 2.0 tokens using the steps described in the previous section.

Because Message Broker V7.0.0.1 offers the SAML pass-through feature, an external security provider is needed to validate the SAML token, unlike the case with Application Server. When the Web service is invoked with the SAML token in the request, the SOAPInput node makes a WS-Trust request to Identity Manager to validate the SAML token with the following attributes in the request:

  • RequestType: http://docs.oasis-open.org/ws-sx/ws-trust/200512/Validate
  • AppliesTo: http://localhost:7800/Secure/services/Hello
  • Issuer: SOAP_WS_SECURITY (you can also set this to REGEXP:(.*) to accept any issuer)
  • TokenType: http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0

Here's how to create the trust chain on Identity Manager to validate the SAML 2.0 token.

  1. On the Identity Manager console, navigate to Tivoli Federated Identity Manager => Configure Trust Service => Trust Service Chains.
  2. Click Create and then click Next for the Introduction page.
  3. Give an appropriate name for the chain -- Validate SAML2.0 for Broker Service in this example -- and click Next.
  4. Select Validate Oasis URI from the Request Type drop-down list. For AppliesTo, enter the URL and Issuer that were mentioned above and select SAML2.0 from the Token Type drop-down list. Click Next and then Next again.
  5. Select Default SAML2.0 Token for the Module Instance and Validate for the Mode, then select Add selected module instance to chain.
  6. On the next page, uncheck both Enable one-time assertion use enforcement and Enable Signature Validation.
  7. Click Next. You should now see a summary page where you can verify the options you just selected. Click Finish.
  8. The chain you just created will be listed in Tivoli Federated Identity Manager => Configure Trust Service => Trust Service Chains. To check or alter the properties, select the chain and click on the properties.

Now you have the trust chains set up on Federated Identity Manager to accept trust requests from Message Broker.

Conclusion

This article showed you how to set up signed and unsigned SAML 2.0-secured communication on Application Server and Message Broker, with Identity Manager used as the Security Token Service. Although this article covered secured communication between client and Web service on Application Server and Message Broker separately, you could also set up communication between a client on Message Broker and a Web service on Application Server or vice-versa using the steps described here so that Message Broker acts as an ESB.

Acknowledgement

Many thanks to Martin Boag from the WebSphere Message Broker Development team for reviewing this article and providing valuable feedback.

Resources

Comments

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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Tivoli (service management), WebSphere, Tivoli, Security
ArticleID=646605
ArticleTitle=Configure secure communications with WebSphere Application Server and WebSphere Message Broker using SAML 2.0 tokens and Tivoli Federated Identity Manager
publish-date=04132011