Rampart is the security module of Axis2. With the Rampart module you can secure web services for authentication (but see below), integrity (signature), confidentiality (encryption/decryption) and non-repudiation (timestamp). Rampart secures SOAP messages according to specifications in WS-Security, using the WS-Security Policy language.
The only specific restriction placed on the use of web service security for IBM Cúram Social Program Management applications is that Rampart Authentication cannot be used. This is due to the requirements of IBM Cúram Social Program Management receivers (this authentication is typically coded in the service code itself, which would be moot by that point as these receivers would have already performed authentication). However, custom SOAP headers provide similar functionality (see Custom SOAP Headers for more details).
WS-Security can be configured using the Rampart WS-Security Policy language. The WS-Security Policy language is built on top of the WS-Policy framework and defines a set of policy assertions that can be used in defining individual security requirements or constraints. Those individual policy assertions can be combined using policy operators defined in the WS-Policy framework to create security policies that can be used to secure messages exchanged between a web service and a client.
WS-security can be configured without any IBM Cúram Social Program Management infrastructure changes using Rampart and WS-Security Policy definitions. A WS-Security Policy document can be embedded in a custom services.xml descriptor (see Deployment Descriptor File). WS-Policy and WS-SecurityPolicy can also be directly associated with the service definition by being embedded within a WSDL document.
Encryption generally incurs costs (e.g. CPU overhead) and this is a concern when using WS-Security. However, there are ways to help minimize these costs and one of these is to set the WS-SecurityPolicy appropriate for each individual operation, message, or even parts of the message for a service, rather than applying a single WS-SecurityPolicy to the entire service (for example, see Encrypting Custom SOAP Headers). To apply such a strategy you need to have a clear grasp of your requirements and exposures. Questions you might consider as you plan your overall security strategy and implementation: Can some services bypass encryption if they are merely providing data that is already available elsewhere publicly? Are multiple levels of encryption necessary; for instance, do you really need both Rampart encryption and HTTP/SSL encryption?