SOA Security made easy with WSAS

Archived Content
This article is provided for historical perspective only, and may not reflect current conditions. Please refer to relevant product page for more up-to-date product information and resources.
  • By Dimuthu Leelarathne
  • 31 May, 2010

WSAS has inbuilt policies for 15 common security scenarios required by the SOA community. You can protect a web service using one of these scenarios within a matter of minutes. You can refer documentation available here for more details.

This tutorial demonstrate how to protect a web service using any valid security policy. Advance use cases require this type of configurations.

This tutorial is written for WSO2 WSAS 3.X.

Step 1 : If the custom policy requires certificates at the server-side (for encrypting, client signature verification) add them to WSAS using Key Stores menu. You can import certificates to the existing key stores or upload your own key stores. If you want to upload a private key you have to first add it into a key store and then upload the key store. Let's call the key store with required certificates and private key as "serv.jks"

Step 2 : If the custom security policy contains a UsernameToken then add all the users who can access the service using Users and Roles menu and assign these users to a role. Let's call this role as "SOA Users".

Step 3 : Host your service in WSAS and go to it's dashboard. Now click on policies under Quality of service.

Step 4 : Security policies are configured as binding policy. Click on “Edit Policy” button on each binding and add the security policy to all the bindings available. If you miss at least one binding the service will not be secured. A sample security policy used for this tutorial is available here. The RampartConfig Policy assertion must be added to your custom policy to configure the key stores and other Rampart specific details.

Each property in Rampart Config can be described as follows.

Step 5 : Click finish. Now the service is secured using the custom policy. Since this is a custom policy it will not be shown in the security management GUI of WSAS. However policy will be picked by Rampart and the service is secure.

Each property in Rampart Config can be described as follows.

Element Name/Property Description
user The user who signs the response.
encryptionUser The encryption user. Then "useReqSigCert" means use the certificate of the request to encrypt the response.
timestampPrecisionInMilliseconds The value is true/false
timestampTTL The TTL of timestamp.
nonceLifeTime The caching lifetime of the Nonce. (On Snapshot builds). If duplicates are recieved within the specified time the message is rejected.
timestampMaxSkew The Max skew of timestamp.
tokenStoreClass The default value is
encryptionCrypto Provider is
signatureCrypto Provider is Alias of the key/certificate Name of the private key store Name of the trust store


Policy Editor in WSAS is a very advanced and powerful tool. Using this method you can apply operation level policies/binding level policies and etc. When using the Policy Editor of WSAS always ensure that your policy is correctly applied by viewing the *.wsdl of the service.