Securing Web Services in JBoss Application Server with WS-Security
The import statement imports the annotation class (#1), and the configName element identifies the configuration you want to use (#2). The valid configurations can be found in the file server/xxx/deploy/jbossws.sar/META-INF/standard-jaxws-endpoint-config.xml. Listing 6 is an excerpt from that file, showing the Standard WSSecurity Endpoint configuration.
Listing 6: Endpoint handler configuration file: standard-jaxws-endpoint-config.xml
<jaxws-config ...> ... <endpoint-config> // Reference #1 <config-name>Standard WSSecurity Endpoint</config-name> <post-handler-chains> <javaee:handler-chain> <javaee:protocol-bindings> ##SOAP11_HTTP </javaee:protocol-bindings> <javaee:handler> <javaee:handler-name> WSSecurity Handler </javaee:handler-name> <javaee:handler-class> // Reference #2 org.jboss.ws.extensions.security.jaxws. WSSecurityHandlerServer </javaee:handler-class> </javaee:handler> </javaee:handler-chain> </post-handler-chains> </endpoint-config> </jaxws-config>
The configuration name given here (#1) matches the configuration name used in the EndpointConfig annotation. The WSSecurityHandlerServer class (#2) handles the encryption and decryption of the messages.
You can add other handler chains to this configuration and even write your own handler by extending the org.jboss.ws.core.jaxws.handler.GenericSOAPHandler. Such a handler has access to and can manipulate the full SOAP message.
Now that you have all the files, you can package them into the hello.war file, as shown in figure 3, and deploy the WAR file.
Figure 3: Here are the contents of hello.war when using WS-Security.
Note that the standard-jaxws-endpoint-config.xml file isn't included in the WAR file; it's picked up from its default location. If you'd like to place that file into the WAR file, you could provide the location using the configFile element on the @EndpointConfig annotation. Once the WAR file deploys, you can access the WSDL file through a browser using the URL http://localhost:8080/jbossws/services.
Securing the client using WS-Security
The client source files don't require any changes to encrypt the message. The only thing you have to do is configure WS-Security. You use two files to correspond to the two configuration files used for the server.
First, provide the information regarding the keystore and truststore. You can do this by creating a jboss-wsse-client.xml file and placing the necessary information into it, as shown in listing 7.
Listing 7: Client configuration file: jboss-wsse-client.xml
<?xml version="1.0" encoding="UTF-8"?> <jboss-ws-security xmlns="http://www.jboss.com/ws-security/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/ws-security/config http://www.jboss.com/ws-security/schema/ jboss-ws-security_1_0.xsd"> <key-store-file>META-INF/client.keystore</key-store-file> <key-store-password>password</key-store-password> <key-store-type>jks</key-store-type> <trust-store-file> META-INF/client.truststore </trust-store-file> <trust-store-password>password</trust-store-password> <trust-store-type>jks</trust-store-type> <key-passwords> // Reference #1 <key-password alias="server" password="clientpwd" /> </key-passwords> <config> <encrypt type="x509v3" alias="server"/> <requires> <encryption/> </requires> </config> </jboss-ws-security>
The contents of this file look similar to that used by the server, the only difference being that the keystore and truststore are located in the META-INF directory. The server public key (#1) is used to encrypt the message, which is decrypted at the server using the server's private key.
You can leave out the information about the keystore, truststore, their passwords, and types, and provide that information using the following system properties:
- org.jboss.ws.wsse.keyStore
- org.jboss.ws.wsse.keyStorePassword
- org.jboss.ws.wsse.keyStoreType
- org.jboss.ws.wsse.trustStore
- org.jboss.ws.wsse.trustStorePassword
- org.jboss.ws.wsse.trustStoreType
Page 3 of 5
This article was originally published on February 13, 2009