Java web services: WS-Security with CXF

See how to use WS-Security with the Apache CXF web services stack
Dennis Sosnoski Architecture Consultant and Trainer Sosnoski Software Solutions, Inc. Skill Level: Intermediate Date: 23 Mar 2010

The Apache CXF web services stack supports WS-Security, including using WS-SecurityPolicy to configure the security handling. CXF is flexible in how you configure the deployment parameters used at run time to implement the security handling, supporting both static and dynamic configuration options for the client side. In this article, Java web services series author Dennis Sosnoski shows how to use CXF for both a simple UsernameToken WS-Security example and one using signing and encryption. View more content in this series Like the Axis2 and Metro web services stacks discussed in earlier articles of this series, Apache CXF (which you met in "Introducing CXF") supports use of the WSSecurity SOAP extension technology to provide a full range of security-related functions for message exchanges. Similar to these other stacks, CXF uses WSSecurityPolicy to configure WS-Security handling (though manual configuration is also possible). CXF's implementation of WS-Security is based on the open source WSS4J library (see Resources). This is the same library used by the Axis2 code, and consequently some of the WS-Security configuration details are similar between the two stacks. The layer of code that interprets WS-SecurityPolicy to configure WSS4J is different, though. In Axis2 it is handled by the separately distributed Rampart module, whereas in CXF it's handled by the cxf-rt-ws-policy and cxf-rt-ws-security modules (included in the standard cxf-#.jar, where # is the version number). In this article, you'll see two examples of configuring WS-Security handling in CXF. The first is a simple UsernameToken that just wraps a plain-text username and password. The second example both signs and encrypts messages, using X.409
© Copyright IBM Corporation 2010 Java web services: WS-Security with CXF Trademarks Page 1 of 16

com/developerWorks/ certificates and keys. but convenient for testing) or as a hash value. the web services stack also requires some additional information to apply the security to a message exchange. For instance. XML and web services consultant Dennis Sosnoski covers the major frameworks and technologies that are important to Java developers using web services. On the server side. UsernameToken Java web services: WS-Security with CXF Page 2 of 16 . WS-SecurityPolicy security configurations detail the security processing needed for messages being exchanged between a client and service. Both Axis2 and Metro use custom WS-SecurityPolicy extensions to provide security parameters of this type. Besides being useful for many applications that want to require direct authentication. These examples match those used with Axis2 in "Axis2 WSSecurity basics" and "Axis2 WS-Security signing and encryption. UsernameToken in CXF provides a standard way of representing a username and password pair with WS-Security. In this case. You'll see how these alternatives for both client and server work in this article's examples. you generally need to modify the WSDL document to add these details (though Axis2 allows you to set a policy directly in client code. The password information can be sent as plain text (normally only used in production when combined with Transport Layer Security [TLS] or WSSecurity encryption." so you can compare techniques to see the differences among the stacks. as an alternative). Since the WS-SecurityPolicy is normally embedded in a WSDL service description. This need to modify the WSDL document is both cumbersome and somewhat contrary to WSDL's intent. a WS-SecurityPolicy may require the client to sign request messages sent to the server. UsernameToken is the simplest form of WS-Security feature and makes a great starting point for examples. On the client side.developerWorks® ibm. Configuration basics About this series Web services are a crucial part of Java technology's role in enterprise computing. you always need to use an XML configuration file. providing nonrepudiation for the service. which is to serve as a service description. See Download to obtain this article's sample code. you can do this either directly in client code or by using a Spring XML configuration file." and with Metro in "WS-Security with Metro. Follow the series to stay informed of the latest developments in the field and be aware of how you can use them to aid your programming projects. In most cases. though you still can choose among different types of files. the client web services stack needs some way of identifying the specific private key to be used for signing when sending a message to the service. CXF takes a different approach — or perhaps that should be different approaches — since there are multiple ways to configure CXF with the added parameters needed when applying a WS-SecurityPolicy configuration to messages. In this series of articles.

org/soap/http"/> <wsdl:operation name="getBook"> <wsdlsoap:operation soapAction="urn:getBook"/> Java web services: WS-Security with CXF Page 3 of 16 . </wsdl:types> <wsdl:message name="getBookRequest"> <wsdl:part element="wns:getBook" name="parameters"/> </wsdl:message> .Empty <TransportBinding/> element required due to bug in CXF 2.2...com/library/wsdl" xmlns:tns="http://ws.ibm... Listing 1.xmlsoap.0.org/ws/2004/09/policy" URI="#UsernameToken"/> <wsdlsoap:binding style="document" transport="http://schemas.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.org/ws/2004/09/policy" xmlns:sp="http://docs.sosnoski.xmlsoap.. Plain-text UsernameToken WSDL <?xml version="1. as is the policy itself.org/wsdl/" xmlns:wsdlsoap="http://schemas.oasis-open.. sent from client to server only --> <wsp:Policy wsu:Id="UsernameToken" xmlns:wsu= "http://docs.com/library/types" xmlns:wsdl="http://schemas." Listing 1 includes policy information to require UsernameToken on requests from the client to the server./IncludeToken/AlwaysToRecipient"/> </wsp:Policy> </sp:SupportingTokens> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> <wsdl:types> ..org/ws-sx/ws-securitypolicy/200702"> <wsp:ExactlyOne> <wsp:All> <!-.xmlsoap. </wsdl:portType> <wsdl:binding name="LibrarySoapBinding" type="wns:Library"> <wsp:PolicyReference xmlns:wsp="http://schemas.sosnoski.0" encoding="UTF-8"?> <wsdl:definitions targetNamespace="http://ws.xmlsoap.Policy for UsernameToken with plaintext password. Listing 1 shows an edited version of the same basic WSDL service definition used in "Introducing CXF. The policy reference in the <wsdl:binding> is shown in bold.com/developerWorks/ developerWorks® To implement a simple plain-text UsernameToken example on CXF. <wsdl:portType name="Library"> <wsdl:operation name="getBook"> <wsdl:input message="wns:getBookRequest" name="getBookRequest"/> <wsdl:output message="wns:getBookResponse" name="getBookResponse"/> </wsdl:operation> .org/wsdl/soap/"> <!-.com/library/wsdl" xmlns:wns="http://ws.xmlsoap.oasis-open..6 --> <sp:TransportBinding/> <sp:SupportingTokens> <wsp:Policy> <sp:UsernameToken sp:IncludeToken=". you need a WSDL service definition with the appropriate WS-Policy/WS-SecurityPolicy configuration included.sosnoski.xsd" xmlns:wsp="http://schemas.

developerWorks® ibm. This version includes an empty <sp:TransportBinding/> element as part of the WS-SecurityPolicy.com/developerWorks/ <wsdl:input name="getBookRequest"> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output name="getBookResponse"> <wsdlsoap:body use="literal"/> </wsdl:output> </wsdl:operation> . Listing 2 shows an example of UsernameToken dynamic configuration in client code: Listing 2.2. Client-side usage Configuring CXF client WS-Security support can be handled either dynamically in client code or statically in configuration files. and a means for validating a username and password on the server side when receiving a request.getLibrary(). ctx. // set the username and password Map ctx = ((BindingProvider)stub). Java web services: WS-Security with CXF Page 4 of 16 . </wsdl:binding> <wsdl:service name="CXFLibrary"> <wsdl:port binding="wns:LibrarySoapBinding" name="library"> <wsdlsoap:address location="http://localhost:8080/cxf-library-username"/> </wsdl:port> </wsdl:service> </wsdl:definitions> There's one significant difference between the Listing 1 WSDL and that used for UsernameToken in the Axis2 and Metro examples. UsernameToken dynamic configuration in client code // create the client stub CXFLibrary service = new CXFLibrary().put("ws-security..getRequestContext(). This error should be corrected in CXF versions later than 2. "libuser"). Library stub = service. or some form of encryption or signing. those parameters are the username and password for the client code to use when sending a request. "books").password". CXF's WSSecurityPolicy handling couldn't process the UsernameToken... As mentioned earlier.2. In this case. The Listing 1 WSDL tells anyone who wants to access the service what needs to be done in terms of the security handling.6 release used for this article. which is necessary because of a bug in the CXF 2.put("ws-security. . to use a policy you generally need to provide additional parameters to CXF. ctx.username"..6. Without a <sp:TransportBinding/>. Next I'll show you examples of how you provide this additional information for each side of the exchange.

com/developerWorks/ developerWorks® A JAX-WS client uses a generated proxy interface to access a service.sosnoski. Although it's not reflected in the API of the generated code. To configure CXF dynamically.xsd http://cxf. By default.xml.file. Listing 3 shows an example of a cxf.apache. Static configuration uses the same property values as the dynamic configuration.org/schemas/jaxws.org/jaxws" xsi:schemaLocation="http://www. the file was not found and you need to look to your classpath to find the cause.BindingProvider class. Listing 2 shows how you can set the username and password for WS-Security handling in this property map.xml. You should see a message INFO: Loaded configuration file cxf.username" value="libuser"/> <entry key="ws-security. (or other file name set using the cxf.ibm. the CXFService class.org/schema/beans http://www. if it finds the file. Java web services: WS-Security with CXF Page 5 of 16 .config. then access the request context property map through that cast.url). You do need to be careful about the configuration file name and placement in the classpath. uses it to set property values. UsernameToken static configuration in cxf. You create an instance of the interface (called a stub in the example code) by calling a method on the generated javax.org/2001/XMLSchema-instance" xmlns:jaxws="http://cxf.config. you can check the INFO-level logging output by the client. In the Listing 2 code. just set in a different way.xml.org/schema/beans/spring-beans-2. which can be used in place of the dynamic configuration shown in Listing 2: Listing 3. since the file is optional and CXF will operate without complaint if the file is not found (until it fails when trying to use WS-Security without the required parameters). if you don't see the message.apache.w3.ws.Service subclass — in this case.apache. you need to make use of this implied typing and cast the proxy to the BindingProvider class.xml and be in a root directory of the classpath (though you can change this default by using a system property. CXF checks for a configuration file in the classpath on startup and.org/schema/beans" xmlns:xsi="http://www.xml file (present in the download code as cxf-usernameclient. If you do run into problems. this is the Library interface.springframework.url system property).org/jaxws http://cxf. the configuration file must be named cxf.xml). cxf.password" value="books"/> </jaxws:properties> </jaxws:client> </beans> The static configuration approach can be convenient when you're using fixed values for WS-Security parameters. JAX-WS guarantees that the returned proxy interface instance is always a subclass of the javax.com/library/wsdl}library" createdFromAPI="true"> <jaxws:properties> <entry key="ws-security.springframework.0.xml <beans xmlns="http://www.file.ws.xsd"> <jaxws:client name="{http://ws.springframework.

UnsupportedCallbackException { for (int i = 0.library. cxf-servlet.org/schema/beans http://www.org/schema/beans/spring-beans-2.0" encoding="UTF-8"?> <beans xmlns="http://www. Server-side callback class ** * Simple password callback handler.ws.xml with added security parameters <?xml version="1.library.org/bindings/soap" xsi:schemaLocation="http://www. you must use a configuration file for your WS-Security parameters.sosnoski. This just handles two cases: matching the username * and password.callback-handler" value="com.cxf.callback.springframework.apache.xsd http://cxf.wsdl" address="/"> <jaxws:properties> <entry key="ws-security.org/schemas/jaxws. wherein the WS-Security code calls a user-supplied callback class implementing the javax.CallbackHandler interface with the username and password information.springframework. i < callbacks.ws.auth.org/jaxws" xmlns:soap="http://cxf." with the added WS-Security information shown in bold (present in the download code as server/etc/cxf-usernameservlet. so it's a technique that allows maximum flexibility. Listing 5.org/jaxws http://cxf.developerWorks® ibm. The callback class can implement any type of handling you want to use to verify the combination of username and password.0. Listing 5 shows the callback class used by the example code. */ public class ServerCallback implements CallbackHandler { public void handle(Callback[] callbacks) throws IOException.apache. The simplest way of doing this is to add the information to the cxfservlet.xsd"> <jaxws:endpoint id="Processor" implementor="com. and providing the password used for access to the private key.org/schema/beans" xmlns:xsi="http://www. This class includes handling for both the UsernameToken case of verifying a username and password and the case of using signing and encryption (discussed in this article's next main section).xml file that defines the service endpoint.springframework.xml used in the "Introducing CXF.org/2001/XMLSchema-instance" xmlns:jaxws="http://cxf.ServerCallback"/> </jaxws:properties> </jaxws:endpoint> </beans> The added configuration information for this UsernameToken case is just a security callback class.sosnoski.length.security.w3.CXFLibraryImpl" wsdlLocation="WEB-INF/wsdl/library-signencr. This is the same approach used in the Axis2 and Metro examples.apache. Listing 4 shows a modified version of the cxf-servlet.com/developerWorks/ Server-side usage On the server side.apache.cxf.xml): Listing 4. i++) { Java web services: WS-Security with CXF Page 6 of 16 .

under the "Server configuration files" topic. since you must directly specify each CXF module you're going to use on the server. open a console to the root directory of the download code and type ant.getUsage()) { case WSPasswordCallback. switch (pwcb.xml.setPassword("serverpass").war file to your test server.equals(id) || !"books". and finally package the server code as a WAR. } } } } As an alternative to using the default cxf-servlet.ibm.getIdentifier(). you may also want to change the host-name and host-port.com/developerWorks/ developerWorks® WSPasswordCallback pwcb = (WSPasswordCallback)callbacks[i]. Signing and encrypting in CXF UsernameToken's simplicity makes it a good starting point. Building and running the sample code Before you can try out the sample code. This approach is a little more complex to implement.DECRYPT: case WSPasswordCallback. case WSPasswordCallback. you need to download and install a current version of CXF on your system (see Resources). or both. printing brief results for each request. This will first invoke the CXF WSDLToJava tool to generate JAX-WS 2. and finally type ant run on the console to try running the sample client. The sample client runs through a sequence of several requests to the server.x data model classes. "check failed"). you can configure a different file for server-side configuration in the web application's web. If you're going to be testing with a server on a different system or port. Most often.SIGNATURE: // used to retrieve password for private key if ("serverkey".xml file.equals(id)) { pwcb.x service classes and JAXB 2. Listing 6 shows an edited example of WSDL using both Java web services: WS-Security with CXF Page 7 of 16 .USERNAME_TOKEN_UNKNOWN: // used when plaintext password in message if (!"libuser". See the CXF documentation "Configuration" page for details.getPassword())) { throw new UnsupportedCallbackException(callbacks[i].properties file in the root directory of the unzipped sample-code download to change the value of the cxf-home property to the path to your CXF installation.xml. but it isn't a typical use of WS-Security. You also need to edit the build. will be involved when you use WS-Security. To build the sample application using the supplied Ant build. either signatures or encryption. then compile the client and server. You can then deploy the generated cxf-library-username. } break.equals(pwcb. but it does allow a faster startup of the web application. } break. String id = pwcb.

" See the Axis2 article for a more-detailed discussion of signing and encrypting in general and for details of generating and using self-signed certificates for WS-Security)./AlwaysToRecipient"> <wsp:Policy> <sp:RequireThumbprintReference/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:InitiatorToken> <sp:RecipientToken> <wsp:Policy> <sp:X509Token sp:IncludeToken="..org/ws-sx/ws-securitypolicy/200702"> <wsp:Policy> <sp:InitiatorToken> <wsp:Policy> <sp:X509Token sp:IncludeToken="./Never"> <wsp:Policy> <sp:RequireThumbprintReference/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:RecipientToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:TripleDesRsa15/> </wsp:Policy> </sp:AlgorithmSuite> <sp:Layout> <wsp:Policy> <sp:Strict/> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp/> <sp:OnlySignEntireHeadersAndBody/> </wsp:Policy> </sp:AsymmetricBinding> <sp:SignedParts xmlns:sp="http://docs.xmlsoap.org/ws/2004/09/policy"> <wsp:ExactlyOne> <wsp:All> <sp:AsymmetricBinding xmlns:sp="http://docs.sosnoski. The policy portions of the WSDL are shown in bold.xsd" xmlns:wsp="http://schemas.org/wsdl/soap/"> <!-.com/developerWorks/ signatures and encryption (based on the examples from "WS-Security with Metro" and the earlier "Axis2 WS-Security signing and encryption. --> <wsp:Policy wsu:Id="SignEncr" xmlns:wsu="http://docs. Signing/encrypting WSDL <?xml version="1..sosnoski.org/wsdl/" xmlns:wsdlsoap="http://schemas.Policy for first signing and then encrypting all messages.xmlsoap.0.com/library/wsdl" xmlns:wns="http://ws.sosnoski..oasis-open.com/library/wsdl" xmlns:tns="http://ws.developerWorks® ibm.. Listing 6..oasis-open.0" encoding="UTF-8"?> <wsdl:definitions targetNamespace="http://ws.org/.xmlsoap.com/library/types" xmlns:wsdl="http://schemas. with the certificate included in the message from client to server but only a thumbprint on messages from the server to the client..oasis-open.-wss-wssecurity-utility-1.org/ws-sx/ws-securitypolicy/200702"> <sp:Body/> Java web services: WS-Security with CXF Page 8 of 16 .

oasis-open. <wsdl:portType name="Library"> .org/ws/2004/09/policy" URI="#SignEncr"/> <wsdlsoap:binding style="document" transport="http://schemas..xmlsoap.org/ws-sx/ws-securitypolicy/200702"> <sp:Body/> </sp:EncryptedParts> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> <wsdl:types> ..1 schema definition.com/developerWorks/ developerWorks® </sp:SignedParts> <sp:EncryptedParts xmlns:sp="http://docs. </wsdl:portType> <wsdl:binding name="LibrarySoapBinding" type="wns:Library"> <wsp:PolicyReference xmlns:wsp="http://schemas. </wsdl:binding> <wsdl:service name="CXFLibrary"> <wsdl:port binding="wns:LibrarySoapBinding" name="library"> <wsdlsoap:address location="http://localhost:8080/cxf-library-signencr"/> </wsdl:port> </wsdl:service> </wsdl:definitions> The only significant difference between the Listing 6 WSDL and that used in the earlier articles is that the WS-Policy/WS-SecurityPolicy portion has been moved to the start of the WSDL. </wsdl:types> <wsdl:message name="getBookRequest"> <wsdl:part element="wns:getBook" name="parameters"/> </wsdl:message> ..... in keeping with the most recent versions of the WSDL 1.. Java web services: WS-Security with CXF Page 9 of 16 ..org/soap/http"/> <wsdl:operation name="getBook"> <wsdlsoap:operation soapAction="urn:getBook"/> <wsdl:input name="getBookRequest"> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output name="getBookResponse"> <wsdlsoap:body use="literal"/> </wsdl:output> </wsdl:operation> .xmlsoap.ibm.

security. you can configure the security parameters needed for signing and encrypting messages either directly in your client code or by using a cxf-client.properties file.keystore.apache.type=jks org.provider=org.security.security.sosnoski.apache.crypto.file=client.keystore Java web services: WS-Security with CXF Page 10 of 16 . one pair for use in signature processing and the other for use in encryption processing.apache.xml configuration file.cxf.properties file org. you'll see how this works for both client and server. You need to identify key stores as the sources of the keys and certificates.springframework.sosnoski.0.merlin.signature.ws. the password used for access to a private key must be supplied by a callback.signature.crypto.keystore. Listing 7 shows a cxf-client.ws.com/developerWorks/ Using private key-certificate pairs for signing and encrypting messages is more complex to configure than the simple UsernameToken example. This file. both properties reference the same client-crypto.developerWorks® ibm.org/2001/XMLSchema-instance" xmlns:jaxws="http://cxf.ws.xml in the download sample code): Listing 7.security. is shown in Listing 8: Listing 8.username" value="clientkey"/> <entry key="ws-security.crypto. Each properties file identifies a key store and provides access information for that store.ClientCallback"/> </jaxws:properties> </jaxws:client> </beans> The Listing 7 cxf-client. cxf-client.w3.xml used for this purpose (cxf-signencr-client.properties" value="client-crypto. The key store information must be provided by a . which must be present in a root directory of the classpath.merlin.callback-handler" value="com.xml with signing and encrypting parameters <beans xmlns="http://www.security.properties" value="client-crypto.org/schemas/jaxws. client-crypto.apache.username" value="serverkey"/> <entry key="ws-security.ws.xsd http://cxf.apache.password=nosecret org.org/schema/beans/spring-beans-2.merlin. which contains both the server certificate and the client private key and certificate. In this case.ws.properties"/> <entry key="ws-security.apache.encryption. the signature processing and the encryption processing use the same key store.properties file.crypto.library.Merlin org.org/jaxws http://cxf.org/schema/beans" xmlns:xsi="http://www. Next.springframework. Client-side usage Just as in the UsernameToken example.properties"/> <entry key="ws-security.encryption. The associated username value identifies the key (for signing) or certificate (for encryption) within that store to be used for processing.springframework.apache.xml defines two pairs of properties file and usernames.com/library/wsdl}library" createdFromAPI="true"> <jaxws:properties> <entry key="ws-security.ws.components. and also provide the passwords needed to access keys from the stores.apache.org/jaxws" xsi:schemaLocation="http://www.xsd"> <jaxws:client name="{http://ws.org/schema/beans http://www. Since there's only one store.crypto.

setPassword("clientpass").callback-handler.properties key in the request context. setting a java. if (usage == WSPasswordCallback. previously seen in the Listing 4 cxf-servlet.equals(id)) { pwcb.xml). */ public class ClientCallback implements CallbackHandler { public void handle(Callback[] callbacks) throws IOException { for (int i = 0.xml file. with the added WS-Security parameters shown in bold: Listing 10.DECRYPT || usage == WSPasswordCallback. the Listing 7 cxf-client. the type of key store. int usage = pwcb.com/developerWorks/ developerWorks® The Listing 8 properties file is used by the underlying WSS4J WS-Security code to configure the signature and encryption processing. you need to include basically the same security parameters as supplied for the client in your cxf-servlet.xml with added security parameters <?xml version="1. } } } } } Just as in the UsernameToken example.getIdentifier(). you can configure the security parameters in your client code as an alternative to using a cxf-client.util.Properties as the value for the ws-security.) Server-side usage On the server side.xml file defines one other parameter — ws-security. cxf-servlet. (See the Listing 2 example of setting the username and password properties in the context. Client-side callback class /** * Simple password callback handler. The WSS4J code will call a instance of this class when it needs to access the password used to secure the client private key within the key store. the key store password. String id = pwcb.length. As in the previous example.encryption. You can even replace the Listing 8 properties file with values you construct in code. This just checks if the password for the private key * is being requested. and the key store file (which must be present in a root directory of the classpath).getUsage().xml file. the value for this parameter must be a security callback handler class. Besides the key store information.SIGNATURE) { // used to retrieve password for private key if ("clientkey". It identifies the "provider" used to handle signature and encryption processing.xml. and if so sets that value. i < callbacks. Listing 10 shows the modified cxf-servlet.ibm.0" encoding="UTF-8"?> Java web services: WS-Security with CXF Page 11 of 16 . i++) { WSPasswordCallback pwcb = (WSPasswordCallback)callbacks[i]. The implementation used in the sample code is shown in Listing 9: Listing 9.xml used in the example code (where you can find it as server/etc/cxfsignencr-servlet.

properties" value="server-crypto.0.properties file is essentially identical to the client-crypto. This value is a special name recognized by WSS4J to mean that the client certificate used to sign the request should be used to encrypt the response.username" value="serverkey"/> <entry key="ws-security.xsd http://cxf. registered.springframework.signature. CXF supports WS-SecurityPolicy in WSDL as a standard approach to WS-Security configuration.signature.sosnoski.apache.CXFLibraryImpl" wsdlLocation="WEB-INF/wsdl/library-signencr.properties file to use variant-name=signencr (rather than the username value for the UsernameToken example). shown in Listing 5. If you run the client using the current 2.developerWorks® ibm. for example WARNING: No assertion builder for type .org/jaxws" xmlns:soap="http://cxf.apache.com/developerWorks/ <beans xmlns="http://www.ws.username" value="useReqSigCert"/> <entry key="ws-security.org/schemas/jaxws. you'll see some WARNINGlevel logging output.xsd"> <jaxws:endpoint id="Processor" implementor="com.library.apache.apache. Other than that.properties shown in Listing 8.callback-handler" value="com. you follow the same build steps as in the UsernameToken example.org/2001/XMLSchema-instance" xmlns:jaxws="http://cxf. These messages do not indicate any problems in the code and will probably be eliminated in later versions of CXF. The server callback class is the same one as in the UsernameToken example.cxf.. you need to change the build.sosnoski.. Using this setting allows the server code to work with multiple clients. Depending on your application needs.ServerCallback"/> </jaxws:properties> </jaxws:endpoint> </beans> The main differences from the client settings are that this server version doesn't specify an encryption properties file.org/schema/beans http://www.springframework. Like Axis2 and Metro.2.org/schema/beans/spring-beans-2. you've seen how to use WS-Security with CXF.properties"/> <entry key="ws-security.org/jaxws http://cxf.library. without embedding deployment Java web services: WS-Security with CXF Page 12 of 16 .cxf. The server-crypto. you can configure the additional required security parameters in several ways.springframework.wsdl" address="/"> <jaxws:properties> <entry key="ws-security.ws.6 version of CXF. and the encryption username setting is useReqSigCert.encryption. Conclusion In this article.org/schema/beans" xmlns:xsi="http://www. each having its own certificate.w3.org/bindings/soap" xsi:schemaLocation="http://www. Building and running the sample code For the signing and encrypting example.

See how CXF performance compares to the latest Axis2 and Metro releases. Testing the example code for this article showed one bug in CXF. both for simple message exchanges and with WS-Security in use. but the design seems sound and it's likely that as more people make use of this relatively new feature of CXF. CXF is easier and cleaner to use for WS-Security than Axis2 and Metro. The next Java web services installment continues with CXF.ibm. In this respect. It's hard to judge the robustness of the CXF WS-SecurityPolicy handling based on the simple examples used in this article. Java web services: WS-Security with CXF Page 13 of 16 . which is being fixed. any quirks in the implementation will be resolved quickly.com/developerWorks/ developerWorks® information in the service WSDL. this time looking at performance. This bug causes the UsernamePolicy to be ignored unless some other form of security processing is also required by the policy.

com/developerWorks/ Downloads Description Source code for this article Information about download methods Name j-jws13.zip Size 28KB Download method HTTP Java web services: WS-Security with CXF Page 14 of 16 .developerWorks® ibm.

• Download IBM product evaluation versions or explore the online trials in the IBM SOA Sandbox and get your hands on application development tools and middleware products from DB2®. Rational®. • Understanding Web Services specifications: This series of tutorials introduces many of the important Web services standards. Tivoli®. • WSS4J: WSS4J is the open source implementation of WS-Security from the Apache Software Foundation. an open source web services stack from the Apache Software Foundation. • OASIS Web Services Security (WSS) TC: This is the organization responsible for the WS-Security specification and token profiles. August 2006) • "Understanding Web Services specifications: WS-Policy" (Tyler Anderson. developerWorks. • OASIS Web Services Secure Exchange (WS-SX) TC: This organization is responsible for WS-SecurityPolicy and related specifications. and WebSphere®. including: • "Understanding Web Services specifications: Web Services Description Language (WSDL)" (Nicholas Chase. July 2006) • "Understanding Web Services specifications: WS-Security" (Nicholas Chase.com/developerWorks/ developerWorks® Resources Learn • Apache CXF: Visit the site for CXF. Java web services: WS-Security with CXF Page 15 of 16 . Get products and technologies • CXF: Download CXF. Both Axis2 and CXF use this library for their WSSecurity processing.ibm. February 2007). • The W3C Web Services Policy Working Group: This group defines the WSPolicy specification. developerWorks. Lotus®. developerWorks. • Get involved in the My developerWorks community. You can find links here to all versions of these standards. Discuss • Apache CXF mailing lists: Subscribe or browse the archives.

as well as a committer on the Apache Axis2 Web services framework. His professional software development experience spans more than 30 years.ibm.com/developerworks/ibm/trademarks/) Java web services: WS-Security with CXF Page 16 of 16 . Dennis is the lead developer of the open source JiBX XML Data Binding framework and the associated JiBX/WS Web services framework. The material for the Java Web Services series is based on Dennis' training classes.ibm.shtml) Trademarks (www. © Copyright IBM Corporation 2010 (www.developerWorks® ibm. with the last 10 focused on server-side XML and Java technologies.com/developerWorks/ About the author Dennis Sosnoski Dennis Sosnoski is a consultant and trainer specializing in Javabased XML and Web services.com/legal/copytrade. He was also one of the Expert Group members for the JAX-WS 2.0 and JAXB 2.0 specifications.