Message-Based Security for SOAP in webMethods: Part 2 (Username_Signature)

Hello all, As promised, here comes my second article in the series of posts on “Message-based security for web services in webMethods.” In case if you missed the first one, here is the link: Message-Based Security for SOAP in webMethods: Part 1

The Plan

There is one essential prerequisite before starting any task, A proper plan. So, our plan going forward is to have hands on below out of the box WS-Security policies Integration Server provides. I will cover one security policy per post, that way it will be short and focused.

Policy Link to the Topic
Username_Over_Transport Message-Based Security for SOAP in webMethods: Part 1
Username_Signature Current post
Username_Encryption Upcoming post
Username_Signature_Encryption Upcoming post

Overview

In the previous post, we have seen a policy that is used to perform open authentication to the server using SOAP header instead of transport header. It was just a different way of presenting credentials on secured endpoints. But, the request and response messages are still unsecured on the wire. Messages can be exposed to threats such as eavesdropping, message replay, etc.

The WS-Security policy design caters to the securing of the message transmission environment between endpoints. You can use authentication safeguards such as signing and encryption at the individual message level to provide greater data protection than just using similar authorization features in a transport-based security.

In this post, we will focus on the “message integrity” which can be achieved using digital signatures. We will be using out of the box policy “Username_Signature” to implement the same.

Username_Signature Policy

This policy uses a Username token to provide client authentication, uses symmetric binding to sign messages to ensure message integrity and includes a Timestamp token to guard against replay attacks. Because this policy uses symmetric binding, the sender of an outbound message does not need a private key. Instead, the client generates a symmetric key.

Prerequisites

  1. Keystore setup with valid keys
  2. Keystore alias creation on Integration Server
  3. Certificates configuration on Integration Server

Info: You must be wondering why we need a keystore if our “Username_Signature” policy is going to use Symmetric Binding for signing the SOAP message. Though symmetric binding is used, WS-Security spec says that the generated symmetric key that is used for signing the message should be encrypted and injected into the SOAP header during the message transmission. In order to do this, public key of the Integration Server should be shared with the client to setup on consumer side. Client then uses this public key to encrypt the symmetric key and inject into the SOAP header. On provider side, integration server uses its private key to decrypt the symmetric key and uses it to verify the signature.

Playground

Enough theory, let’s get started with the implementation.

First, you should be ready with a Keystore with your pair of keys (public and private). If you do not have one, then create a Keystore using Java toolkit. You can refer to this link to learn how to do the same.

Once ready, you have to create Keystore and Truststore Aliases on Integration Server.

  1. On Integration Server Administration screen, Navigate to Security > Keystore
  2. You will see two create links Create Keystore Alias and Create Truststore Alias
    • Info: Integration server used the keys from the configured Keystores to perform safeguard activties like Signing or Decrypting a message i.e., using private keys. Truststore will be used to perform the counter part of the previously mentioned safeguards which are Verifying or Encrypting a message i.e., using public keys.

  3. Click on Create Keystore Alias. Fill in the details and click on Submit button
    keystore
  4. Make sure your custom Keystore alias is created and loaded
    keystore_created

Now that required configuration is done let us see the policy enforcement on Webservice.

Policy Enforcement on Webservice Provider

  1. First, we shall create an Endpoint alias for the provider so that all the necessary configuration can be saved at server administration
  2. Navigate to Settings Web Services on Integration server management page
  3. Click on Create Web Service Endpoint Alias
  4. Fill in details as shown in screenshot below
    providerendpointalias
  5. Notice that we have selected the Keystore Alias and Key Alias that we have created earlier

    Info: Web service provider uses this keystore to get the private key that is required to decrypt the symmetric token from inbound SOAP message header. After decrypting, it used this symmetric key to verify the digitally signed SOAP message for its integrity. If the keystore details are not mentioned in the endpoint alias, then Integration server will look for them at server level. So, make sure you configured server level certificates at SecurityCertificates in Integration server administration.

  6. Click on Save Changes
  7. Now, Open your Webservice provider descriptor in Software AG Designer and attach the “Username_Signature” policy to it. If you are new to this, then refer to the Attaching the Policy section from the previous post.
  8. We should now bind the provider endpoint alias we created earlier to the web service binder.
  9. Click on Binders tab. Select the binder and from the Properties section choose the Port alias as the provider endpoint alias
    provideraliasenforcement

Policy enforcement on Web Service Consumer

We shall follow similar steps we took for the implementation of policy on Webservice provider.

  1. Create an endpoint alias for the consumer on IS
  2. Navigate to Settings Web Services on Integration server administration page
  3. Click on Create Web Service Endpoint Alias
  4. Fill in details as shown in screen shot below:

    Info: Parter’s Certificate in the below details is public key of the server on which web service provider is hosted. For this demo, you can export the public key certificate from the keystore you created using Java toolkit. Check this short tutorial to know about the same.

    consumerendpointalias

  5. Notice that we have not provided the details of Keystore in the consumer endpoint alias as it is not required (at least for this moment, i.e., for Username_Signature policy). Only Partner’s Certificate is required to encrypt the symmetric key that is used for signing the SOAP message.
  6. Click on Save Changes
  7. Now, Open your Webservice consumer descriptor in Software AG Designer and attach the “Username_Signature” policy to it. If you are new to this, then refer to the Attaching the Policy section from the previous post.
  8. We should now bind the consumer endpoint alias we created earlier to the web service binder.
  9. Click on Binders tab. Select the binder and from the Properties section choose the Port alias as the consumer endpoint alias

All the setup is done. Now just go to the connector service and RUN it. Provide the required inputs and click OK. You should get the sum of the numbers as the response.

Verification

To verify if the policy is being enforced, SOAP message is being signed, and symmetric key is being encrypted, the only best way is to have a look at the SOAP message itself.

But unfortunately, there is no fair way to have an eye on this on Integration server. Increasing SOAP log levels would help only a little, but it is definitely not a relatively obvious option. So, my favorite in this case is TCPMon utility.

Info: TCPMon is a light-weight request sniffing utility which comes very handy for monitoring the request/response of HTTP transactions. It allows you to enable a proxy port which will accept the original request and forwards it to the original intended endpoint.

I have launched my TCPMon on port 15555, pointed my consumer endpoint alias to this TCPMon port and re-ran the Webservice connector. Below is how the request and response were captured on the wire.

tcpmon

These long series of tags in the SOAP header are the result of various assertions inside the policy. If zoomed in, it can also be noticed that the digest of signed message is part of the header along with the encrypted symmetric key.

With this, I conclude this article, and I hope you got some understanding on the second level of security, i.e., signing SOAP messages for their integrity.

You’ve now learned following things today:

  1. How to Configure Keystores on Integration Server.
  2. How to set endpoint aliases for provider and consumer with certificate related details
  3. How to bind endpoint aliases to Webservice descriptors
  4. How to monitor a request-response going out of Webservice connector using TCPMon

Thank you for reading this post and #happy_integration

Advertisements

6 thoughts on “Message-Based Security for SOAP in webMethods: Part 2 (Username_Signature)

  1. Hello Pokala,

    Thanks for a detailed step by step blog.
    One thing I confused is that in part one – you have given name of the policy as Username_Token and in the current blog you are refering it as Username_Over_Transport . can u please let me know if the both the policies are same.

    Thanks

    Liked by 1 person

    1. Thanks, Vemuri. Both the policies are same by their nature but not assertion to assertion. What I mean is, in part 1 I was trying to explain just message based authentication (without digital signature, encryption, etc..). These two policies would do the same about that. But, if you open the policy files of Username_Token and Username_Over_Transport, they will look different. Because there are few more assertions inside the second one like HTTPS protocol enforcement. As I did not want to cover that part, I had to modify the policy file “username_over_transport” by removing some assertions and rename it as “username_token.”

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s