1 | Configuration notes for use with axis2.xml |
---|
2 | ------------------ |
---|
3 | |
---|
4 | The axis2.xml file contained in this directory is used by the java client, |
---|
5 | axis2/xmlbWsseEchoClient/src/wssecurity.test.security.ndg/EchoClient.java |
---|
6 | to set up the required webservice security configuration for communicating with the |
---|
7 | secure Echo service - provided by TI12-security-trunk/python/ndg.security.test/ndg/security/test/wsSecurity/server/echoServer.py |
---|
8 | - using the Rampart library which is built on the wss4j framework. |
---|
9 | |
---|
10 | A brief explanation of the contents follows: |
---|
11 | |
---|
12 | <module ref="rampart" /> - enables the rampart module |
---|
13 | |
---|
14 | <parameter name="OutflowSecurity"> - the security set on outgoing SOAP messages |
---|
15 | <action> |
---|
16 | <items>Timestamp Signature</items> - add a timestamp to the SOAP Header and then add signature |
---|
17 | <user>client</user> - the username used to complete the action. This is used by the passwordCallbackClass to determine the password to the keystore specified in client.properties. NB, the example Handler is |
---|
18 | a dummy file; in a production system, this data should be looked up via LDAP or some other authentication/authorisation system |
---|
19 | <signaturePropFile>client.properties</signaturePropFile> - the client.properties file to use; if no filepath is included, the location is assumed to be the dir above the source package dir |
---|
20 | <passwordCallbackClass>ndg.security.client.PWCBHandler</passwordCallbackClass> - class to handle password callback - i.e. to lookup the keystore passoword for the user specified in the user element |
---|
21 | <signatureKeyIdentifier>DirectReference</signatureKeyIdentifier> - key id to be used in referring the key in the signature. If 'DirectReference' is used, rampart adds the client's public key to the |
---|
22 | header as a BinarySecurityTokene and adds a reference to it from the signature; this allows the services to process the client request without needing to have the client public key |
---|
23 | in its keystore. |
---|
24 | <signatureParts>{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body</signatureParts> - use this |
---|
25 | to specify additional elements to add to the SOAP Header SignatureValue. Also, see (3). |
---|
26 | </action> |
---|
27 | </parameter> |
---|
28 | |
---|
29 | <parameter name="InflowSecurity"> - the security to expect on incoming SOAP messages |
---|
30 | <action> |
---|
31 | <items>Signature Timestamp</items> - see (2) |
---|
32 | <signaturePropFile>client.properties</signaturePropFile> |
---|
33 | <passwordCallbackClass>wssecurity.test.security.ndg.PWCBHandler</passwordCallbackClass> |
---|
34 | </action> |
---|
35 | </parameter> |
---|
36 | |
---|
37 | |
---|
38 | Further notes: |
---|
39 | 1) Other actions are available - including Encrypt, if the message body needs encrypting; if this is set, elements need to be included to identify |
---|
40 | the encrypt/decrypt user or key to use |
---|
41 | 2) The order the actions are specified in is important; they must be mirrored across the |
---|
42 | the client-server comms. If there is a mismatch, the following error is likely to be thrown |
---|
43 | by the client (NB, tcpmon will still show the correct message response): |
---|
44 | org.apache.axis2.AxisFault: WSDoAllReceiver: security processing failed (actions mismatch) |
---|
45 | 3) It does not appear to be possible to add the BinarySecurityToken to the Signature; including it in |
---|
46 | the signatureParts element leads to the exception: |
---|
47 | General security error (WSEncryptBody/WSSignEnvelope: Element to encrypt/sign not found |
---|
48 | |
---|