SOA Security made easy with WSAS

WSO2 offers a set of powerful tools that makes implementing SOA an easy task. WSO2 WSAS is a lightweight application server for Web services. It simplifies WS-Security to several clicks for beginners. It also enables advance users to exploit the full power of Apache Rampart.

Date: Mon, 31st May, 2010
Level: Intermediate
Reads: 2491 Comments: 0 | Login or register to post comments
dimuthu leelarathne
Tech LEad
WSO2
dimuthul's picture

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
userThe user who signs the response.
encryptionUserThe encryption user. Then "useReqSigCert" means use the certificate of the request to encrypt the response.
timestampPrecisionInMillisecondsThe value is true/false
timestampTTLThe TTL of timestamp.
nonceLifeTimeThe caching lifetime of the Nonce. (On Snapshot builds). If duplicates are recieved within the specified time the message is rejected.
timestampMaxSkewThe Max skew of timestamp.
tokenStoreClassThe default value is org.wso2.carbon.security.util.SecurityTokenStore
encryptionCryptoProvider is org.wso2.carbon.security.util.ServerCrypto
signatureCryptoProvider is org.wso2.carbon.security.util.ServerCrypto
org.wso2.carbon.security.crypto.aliasAlias of the key/certificate
org.wso2.carbon.security.crypto.privatestoreName of the private key store
org.wso2.carbon.security.crypto.truststoresName of the trust store
Conclusion

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.