SOA Security made easy with WSAS
- Dimuthu Leelarathne
- Architect - WSO2
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 org.wso2.carbon.security.util.SecurityTokenStore |
encryptionCrypto | Provider is org.wso2.carbon.security.util.ServerCrypto |
signatureCrypto | Provider is org.wso2.carbon.security.util.ServerCrypto |
org.wso2.carbon.security.crypto.alias | Alias of the key/certificate |
org.wso2.carbon.security.crypto.privatestore | Name of the private key store |
org.wso2.carbon.security.crypto.truststores | Name 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.