Implementing a simple WS-Trust server in WebSphere Message Broker using a database

Small and mid-sized enterprises often don't have LDAP or IBM Tivoli Federated Identity Manager to manage web services security in their ESB infrastructure. This article shows you how to implement a simple WS-Trust Server using a database to manage authentication. You can easily extend this example to add the authorization part of web services security.

Chary Eswarachary (lingeswa@us.ibm.com), Senior Integration Architect, IBM Software Services for WebSphere, IBM

Photo of Chary EswaracharyLingachary Eswarachary is a Senior WebSphere Integration Architect at IBM Software Services for WebSphere in the US. He has 17 years of experience in the IT Industry, of which 10 years were spent working with IBM Software Group in the connectivity space. He architects, designs, and implements WebSphere solutions, and supports the end-to-end software development cycle using Smart SOA approaches. His areas of expertise include WebSphere DataPower, WebSphere Message Broker, WebSphere MQ, and WebSphere Transformation Extender. He is an IBM Redbooks author and a Certified SOA Associate, and he has several IBM product certifications. He has helped develop IBM product certification programs, and he conducts training and workshops on WebSphere and related products. You can contact Lingachary at lingeswa@us.ibm.com.



25 April 2012

Introduction

This article shows you how to implement a simple Security Token Server (WS-Trust Server) in IBM® WebSphere® Message Broker V8 (hereafter called Message Broker). You create a Security Token Service (STS) in a message flow, and then use the service to manage your authentication needs. For password encryption, the Java® Simplified Encryption (Jasypt) open-source Java library is used.

Design

As shown below, the design includes a TempConvService that takes a SOAP request to convert temperature from Fahrenheit to Celsius, but internally uses a vendor-supplied temperature service. The security-enabled SOAPInput node acts as the Policy Enforcement Point (PEP) and invokes STS for authentication, which acts as the Policy Decision Point (PDP). At PEP, the broker invokes WMBSTSService running on the broker, which authenticates the user using the WMBSTSDB database. Upon authentication, WMBSTSService returns a valid or invalid message to the SOAPInput node. Based on the authentication response, the SOAPInput node either throws a security exception, or continues with the next node in the flow:

Figure 1. Pre-built message flows
Pre-built message flows

Message flows

Three pre-built message flows are provided as shown below: the Temperature Converter Service (which needs to be secured), the WS-Trust Service (STS service flow), and the Password Utility Service. These three message flows are used to demonstrate message flow authentication.

TempConvService flow
TempConvService flow
WMBSTSService flow
WMBSTSService flow
PasswordUtility flow
PasswordUtility flow

TempConvService flow (unsecured)

In the TempConvService message flow, you create a web service that converts a temperature from Fahrenheit to Celsius. This service needs to be secured against unauthorized users. This message flow is created within the TempConvService application container, and it uses an existing web service from w3schools.

  1. Import the WSDL from w3schools and configure the SOAPInput node's Basic and HTTP Transport tabs as follows:
  2. Import the same WSDL again and configure the SOAPRequest node's Basic and HTTP Transport tabs as follows:
  3. Create a BAR file named TempConvService.bar and deploy the flow.
  4. Test the flow using the soapUI tool. The TempConv message flow is not configured for user authentication at this point and is tested as an unsecured message flow. The URL used to invoke the TempConv broker service is http://localhost:7800/TempConvService:

WMBSTSService flow

This flow implements a security token server according to the WS-Trust V1.3 specification. The flow uses WS-Trust V1.3 WSDL and the schema referenced by the WSDL. This flow is created within the WMBSTS_Library container. To keep the flow simple, the SOAPRequest node is configured to operate in gateway mode, since there are multiple messages defined in the WS-Trust V1.3 schema. For the purpose of this flow, two messages are used: RequestSecurityTokenCollection for input, and RequestSecurityTokenResponseCollection for output. Configure the SOAPRequest node as follows:

The Compute node is configured to connect to the WMBSTSDB data source. It retrieves the encrypted password from the STS database and authenticates the user. Upon authentication, the flow returns a valid or invalid message depending on whether the user id and password matched or not. If there is any exception in the flow, the flow returns the invalid message because the user could not be authenticated. The Jasypt library is used to decrypt the password.

This flow requires a Java project, a database setup, and a password utility flow. The Java project provides an API to encrypt and validate passwords. The database holds userids and the encrypted user passwords. The password utility flow is a helper flow that can be used to encrypt and validate passwords stored in the STS database. This flow also uses the Java project.

WMBSTS_Library_Java project

Create a Java project named WMBSTS_Library_Java for encrypting and validating passwords using the Jasypt library. This project has only one file, WMBSTSService_Library.java, as shown below:

The WMBSTSService_Library class has two methods: encrypt() and verifyPassword(). Make sure that you copy jasypt-1.9.0.jar and icu4j-3.4.4.jar from the Jasypt package to the broker's shared classes directory, and then restart the broker.

PasswordUtility Flow

This flow is provided as a helper flow that you can use to encrypt and validate the password stored in the STS database. This flow is also created within the WMBSTS_Library container. For encryption, it takes an XML input with the password in plain text, and returns an encrypted password. For validation, an XML input with both plain text and encrypted password values is passed. This flow uses the Jasypt library for password encryption and validation.

  1. Create a BAR file named WMBSTS_Library.bar and deploy the PasswordUtility flow.
  2. Test the flow using the soapUI tool. The following screenshots show password encryption and validation tests:

Database configuration

  1. This example uses DB2 V9.7. Define a database named WMBSTSDB and a data source with the same name. Then create a table called PASSWORD with three columns named USERID, PWDCLEAR, and PWDCRYPTED, as shown below. While PWDCLEAR may be used for storing clear-text passwords, it is not generally recommended and so will not be used in this exercise.
  2. After the table is created, insert a row as shown below using the DB2 command window. The password Chary inserted for user Chary is already encrypted using the Jasypt library:
    db2 insert into PASSWORD values('Chary',null,'n9xwRvS/foqvPqfKo/XmvLWm3VFBIAnq')
  3. Configure the database userid and password with the broker using the mqsisetdbparms command.

Testing and deployment

Testing the WMBSTSService Flow

  1. Add WMBSTSService Flow to WMBSTS_Library.bar and redeploy. Test the WMBSTSService flow using the soapUI tool:

Security configuration

  1. To enable TempConvService with security for authentication, open up TempConvService.bar and configure the SOAP Input node's Policy Set, Policy Set Bindings, and Security profile properties:
  2. Configure Policy Set and Policy Set Bindings properties to the default value WSS10Default, and Security profile to STSSecurityProfile. Save the BAR file.
  3. Using the Broker command console, create a security profile STSSecurityProfile, as shown below:
    mqsicreateconfigurableservice BROKER8 -c SecurityProfiles –o STSSecurityProfile –n
    authentication,authenticationConfig -v 
    "WS-Trust v1.3 STS",http://localhost:7800/WMBSTSService
  4. Deploy the modified TempConvService.bar file.

Testing the secured TempConvService flow

  1. Using the soapUI tool, create the WS-Security configuration wsse for outgoing requests, as shown below. The configured password is the same as the userid.
  2. Configure authentication for outgoing requests by setting the Outgoing WSS property to wsse in the Aut tab of the request:
  3. Send the request and verify the response:
  4. Verify authentication failure by configuring a wrong password. You should see FailedAuthentication faultcode, as shown below:

Deployment

  1. Deploy all three flows to the same execution group. The WMBSTSService and PasswordUtility message flows are part of the library container WMBSTS_Library, and the TempConvService flow is in the application container TempConvService:

Conclusion

You can easily extend the example in this article to include the authorization part of the security services.


Download

DescriptionNameSize
Code samplesample.zip3.6 MB

Resources

  • Web services security resources
    • Using Web Services Trust (WS-Trust) for token transformation
      WS-Trust provides a standard way to send security token requests to a Security Token Service (STS), and this specification can be used to manage token transformation when crossing the various security boundaries of the information system. This article introduces WS-Trust concepts and its basic use to manage token exchange.
    • WS-Trust Language
      The WS-Trust language uses the secure messaging mechanisms of WS-Security to define additional primitives and extensions for security token exchange to enable the issuing and dissemination of credentials within different trust domains.
    • SOA: Managing identity contexts across service requests
      In SOA, the reuse of applications and services across organizational, trust, and technological boundaries creates a number of challenges. The identity and credential systems can vary, and therefore managing, mapping, and propagating identity across these environments is necessary. This article describes the business challenges when managing identity contexts in web services and SOA, and 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.
    • Implementing message flow security in WebSphere Message Broker V7
      You can configure WebSphere Message Broker to perform access control for individual messages in a message flow by using an external security provider. This article describes security at the message-flow level and shows you how to implement message-flow security.
    • Implementing Web Services Security (WS-Security) in WebSphere Message Broker V7
      A WebSphere Message Broker application can participate in a web services environment as a service requester, service provider, or both. WS-Security is a set of enhancements to SOAP messaging that provides user authorization and authentication, message integrity, and message confidentiality. This article shows you how to implement WS-Security in message flows using the Message Broker SOAP nodes.
  • WebSphere Message Broker resources
  • WebSphere resources
  • developerWorks resources
    • Trial downloads for IBM software products
      No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
    • developerWorks blogs
      Join a conversation with developerWorks users and authors, and IBM editors and developers.
    • developerWorks cloud computing resources
      Access the IBM or Amazon EC2 cloud, test an IBM cloud computing product in a sandbox, see demos of cloud computing products and services, read cloud articles, and access other cloud resources.
    • developerWorks tech briefings
      Free technical sessions by IBM experts to accelerate your learning curve and help you succeed in your most challenging software projects. Sessions range from one-hour virtual briefings to half-day and full-day live sessions in cities worldwide.
    • developerWorks podcasts
      Listen to interesting and offbeat interviews and discussions with software innovators.
    • developerWorks on Twitter
      Check out recent Twitter messages and URLs.
    • IBM Education Assistant
      A collection of multimedia educational modules that will help you better understand IBM software products and use them more effectively to meet your business requirements.

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 WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=812041
ArticleTitle=Implementing a simple WS-Trust server in WebSphere Message Broker using a database
publish-date=04252012