Securing Web Services in JBoss Application Server with WS-Security, Page 4
If you specify this information both in the configuration file and as system properties, the configuration file takes precedence. Additionally, because the same class handles the jboss-wsse-client.xml and jboss-wsse-server.xml files, the system properties could be used for the server also. Because the server might serve multiple Web Services, each with their own WS-Security configuration, it makes sense that the settings in the configuration file take precedence over the system properties.
You have to state that you want to use WS-Security by creating a META-INF/standard-jaxws-client-config.xml file. An example of this file can be found at server/xxx/deploy/jbossws.sar/META-INF/standard-jaxws-client-config.xml. Copy this file to your project and edit it, removing the configurations that you don't want. The only configuration you should leave is Standard WSSecurity Client, as shown in listing 8.
Listing 8: Client configuration file: standard-jaxws-client-config.xml
<?xml version="1.0" encoding="UTF-8"?> <jaxws-config xmlns="urn:jboss:jaxws-config:2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="urn:jboss:jaxws-config:2.0 jaxws-config_2_0.xsd"> <client-config> <config-name>Standard WSSecurity Client</config-name> <post-handler-chains> <javaee:handler-chain> <javaee:protocol-bindings> ##SOAP11_HTTP </javaee:protocol-bindings> <javaee:handler> <javaee:handler-name> WSSecurityHandlerOutbound </javaee:handler-name> <javaee:handler-class> // Reference #1 org.jboss.ws.extensions.security.jaxws. WSSecurityHandlerClient </javaee:handler-class> </javaee:handler> </javaee:handler-chain> </post-handler-chains> </client-config> </jaxws-config>
The WSSecurityHandlerClient (#1) is the client-side handler that corresponds to the WSSecurityHandlerServer server-side handler. Both of these classes defer to the WSSecurityHandler class to handle the messages.
All that's left to do is package the files into a JAR file as illustrated in figure 4.
Figure 4: Here are the contents of the client.jar file when using WS-Security.
Once you have the JAR file, you can run the client, once again using wsrunclient. It should work. You can verify that the messages are encrypted by turning on message tracing. Uncomment the Enable JBossWS message tracing entry in the jboss-log4j.xml file before starting the application server. Then look for the org.jboss.ws.core.MessageTrace entries in the server.log file.
Signing the messages using WS-Security
WS-Security provides a mechanism to sign a message, providing an alternate means of authenticating the user. To illustrate how this works, we modify the example that encrypts messages.
For signing a message, the sender uses his or her private key, and the receiver uses the sender's public key to verify the sender's identity. This means that the client's public key must be in the server's truststore and the server's public key must be in the server's truststore. This configuration is illustrated in figure 5.
Figure 5: Here are the relationships among the key and trust stores for signing messages. The only difference between this and figure 1 is that the other system's public key has been added to the truststore.
Assuming that the keystores and truststores are already set up for encryption, here are the additional commands used to create this configuration:
keytool -import -alias server -keystore client.truststore \ -file server_pub.key keytool -import -alias client -keystore server.truststore \ -file client_pub.key