This tutorial by Malinda Kaushalye Kapuruge is an extension to his previous tutorial titled "Dummy's guide to WSO2 WSF/C" [1]. It is expected that you complete that tutorial before starting with this one. Here, we will discuss how to secure SOAP messages using the WSO2 WSF/C framework.

Applies To

Table of Contents

• Prerequisites [1]
• Install WSO2 WSF/C with Rampart/C [1]
• The Module Deployed [1]
• Your Secured Service [1]
• Security Policies, Defining the Behavior [1]
• Writing a Secured Client [1]
• Trying Security Samples [1]
  • Service [1]
  • Client [1]
  • Run [1]
• Conclusion [1]

"Dummy's guide to WSO2 WSF/C" [2] for detailed instructions. By default, Apache Rampart/C, which is the security module of WSF/C is installed with the framework.

Alternatively, you may refer the Installation Guide here [3].

 

module.xml [3] that defines the phases Rampart handlers should be resident. To understand more on modules, handlers and phases in Axis2/C, please refer this [4] article.

In the module.xml file, you'll see that we have added a phase called Security for the outflow (i.e the Outgoing message flow). This is a phase unique to Rampart/C. So please open the file named WSFC_HOME/axis2.xml and see whether the "Security" phase is defined for the outflow as given below:

<phaseOrder type="outflow">
        <phase name="RMPhase"/>
        <phase name="SavanPhase"/>
        <phase name="userphase1"/>
        <phase name="MessageOut"/>
        <phase name="Security"/>
    </phaseOrder>

 

services.xml [4] file. Open the README file along with these sample scenarios and you'll see a short description that defines what each scenario does. For example, scenario3 gives you the security policy configurations for message level encryption.

The second category of policies are mainly for local settings. These policies are defined by the WSF/C security module and usually contains information such as, where to feed the certificates/keys, the valid duration (time to live) of a message etc. Following is an example of such a policy. It defines where to load the service's certificate:

<rampc:ReceiverCertificate>/WSFC_HOME/bin/samples/rampart/keys/bhome/alice_cert.cert</rampc:ReceiverCertificate>

At most times, it is necessary to combine both kinds of policies to enforce a particular security requirement. For example, if a service requests Username token based authentication, then the service deployer has to have a combination of both a custom policy (for password callback module) and a standard policy (for enforcing username tokens).

<!--Standard policy Enforcing Username tokens-->
<wsp:Policy>
    <sp:UsernameToken sp:IncludeToken="http://.../IncludeToken/Always"/>
</wsp:Policy>
 ...
<!--Custom policy for the password callback module-->
<rampc:PasswordCallbackClass>WSFC_HOME/bin/samples/rampart/callback/libpwcb.so</rampc:PasswordCallbackClass>

 

policy file [4] name as a string argument to the function neethi_util_create_policy_from_file(). Here the policy_file_name is the file name for your policy configurations on the client side. If we recall the service's equivalent of this, there we added our policies to the service descriptor file but for the client side, we place them in separate file. You may find such client policy files for each and every security requirement in the scenarios available under WSFC_HOME/rampartc/samples/secpolicy.

 

here [5].

The sample shows the encryption scenario. There are twelve other scenarios shipped with the WSF/C distribution that you can try yourself.

 

WSO2 WSF/C [6]

OpenSSL [7]

Apache Axis2/C [8]

Apache Rampart/C [9]

 

Author

Malinda Kaushalye Kapuruge is a Senior Software Engineer, WSO2 Inc. kaushalye at wso2 dot com