Apache CXF的Web服务安全WS-Security

jieforest

Client-side usage

Just as in the UsernameToken example, you can configure the security parameters needed for signing and encrypting messages either directly in your client code or by using a cxf-client.xml configuration file. Listing 7 shows a cxf-client.xml used for this purpose (cxf-signencr-client.xml in the download sample code):

Listing 7. cxf-client.xml with signing and encrypting parameters

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:jaxws="http://cxf.apache.org/jaxws"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
   http://cxf.apache.org/jaxws
   http://cxf.apache.org/schemas/jaxws.xsd">

  <jaxws:client name="{http://ws.sosnoski.com/library/wsdl}library"
      createdFromAPI="true">
    <jaxwsroperties>
      <entry key="ws-security.signature.properties"
          value="client-crypto.properties"/>
      <entry key="ws-security.signature.username" value="clientkey"/>
      <entry key="ws-security.encryption.properties"
          value="client-crypto.properties"/>
      <entry key="ws-security.encryption.username" value="serverkey"/>
      <entry key="ws-security.callback-handler"
          value="com.sosnoski.ws.library.cxf.ClientCallback"/>
    </jaxwsroperties>
  </jaxws:client>

</beans>


The Listing 7 cxf-client.xml defines two pairs of properties file and usernames, one pair for use in signature processing and the other for use in encryption processing. Each properties file identifies a key store and provides access information for that store. The associated username value identifies the key (for signing) or certificate (for encryption) within that store to be used for processing. In this case, the signature processing and the encryption processing use the same key store, which contains both the server certificate and the client private key and certificate. Since there's only one store, both properties reference the same client-crypto.properties file. This file, which must be present in a root directory of the classpath, is shown in Listing 8:

jieforest

Listing 8. client-crypto.properties file

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=nosecret
org.apache.ws.security.crypto.merlin.file=client.keystore


The Listing 8 properties file is used by the underlying WSS4J WS-Security code to configure the signature and encryption processing. It identifies the "provider" used to handle signature and encryption processing, the type of key store, the key store password, and the key store file (which must be present in a root directory of the classpath).

Besides the key store information, the Listing 7 cxf-client.xml file defines one other parameter — ws-security.callback-handler, previously seen in the Listing 4 cxf-servlet.xml. As in the previous example, the value for this parameter must be a security callback handler class. 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 implementation used in the sample code is shown in Listing 9:

jieforest

Listing 9. Client-side callback class

/**
* Simple password callback handler. This just checks if the password for the private key
* is being requested, and if so sets that value.
*/
public class ClientCallback implements CallbackHandler {
  public void handle(Callback[] callbacks) throws IOException {
    for (int i = 0; i < callbacks.length; i++) {
      WSPasswordCallback pwcb = (WSPasswordCallback)callbacks;
      String id = pwcb.getIdentifier();
      int usage = pwcb.getUsage();
      if (usage == WSPasswordCallback.DECRYPT || usage == WSPasswordCallback.SIGNATURE) {

         // used to retrieve password for private key
         if ("clientkey".equals(id)) {
             pwcb.setPassword("clientpass");
         }

      }
    }
  }
}


Just as in the UsernameToken example, you can configure the security parameters in your client code as an alternative to using a cxf-client.xml file. You can even replace the Listing 8 properties file with values you construct in code, setting a java.util.Properties as the value for the ws-security.encryption.properties key in the request context. (See the Listing 2 example of setting the username and password properties in the context.)

jieforest

Server-side usage

On the server side, you need to include basically the same security parameters as supplied for the client in your cxf-servlet.xml file. Listing 10 shows the modified cxf-servlet.xml used in the example code (where you can find it as server/etc/cxf-signencr-servlet.xml), with the added WS-Security parameters shown in bold:

Listing 10. cxf-servlet.xml with added security parameters

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jaxws="http://cxf.apache.org/jaxws"
    xmlns:soap="http://cxf.apache.org/bindings/soap"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
      http://cxf.apache.org/jaxws
      http://cxf.apache.org/schemas/jaxws.xsd">

  <jaxws:endpoint id="Processor"
      implementor="com.sosnoski.ws.library.cxf.CXFLibraryImpl"
      wsdlLocation="WEB-INF/wsdl/library-signencr.wsdl"
      address="/">

    <jaxwsroperties>
      <entry key="ws-security.signature.properties" value="server-crypto.properties"/>
      <entry key="ws-security.signature.username" value="serverkey"/>
      <entry key="ws-security.encryption.username" value="useReqSigCert"/>
      <entry key="ws-security.callback-handler"
          value="com.sosnoski.ws.library.cxf.ServerCallback"/>
    </jaxwsroperties>

  </jaxws:endpoint>
</beans>


The main differences from the client settings are that this server version doesn't specify an encryption properties file, and the encryption username setting is useReqSigCert. 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. Using this setting allows the server code to work with multiple clients, each having its own certificate.

The server-crypto.properties file is essentially identical to the client-crypto.properties shown in Listing 8. The server callback class is the same one as in the UsernameToken example, shown in Listing 5.

jieforest

Building and running the sample code

For the signing and encrypting example, you need to change the build.properties file to use variant-name=signencr (rather than the username value for the UsernameToken example). Other than that, you follow the same build steps as in the UsernameToken example.

If you run the client using the current 2.2.6 version of CXF, you'll see some WARNING-level logging output, for example WARNING: No assertion builder for type ... registered. These messages do not indicate any problems in the code and will probably be eliminated in later versions of CXF.

jieforest

Conclusion

In this article, you've seen how to use WS-Security with CXF. Like Axis2 and Metro, CXF supports WS-SecurityPolicy in WSDL as a standard approach to WS-Security configuration. Depending on your application needs, you can configure the additional required security parameters in several ways, without ××ding deployment information in the service WSDL. In this respect, CXF is easier and cleaner to use for WS-Security than Axis2 and Metro.

Testing the example code for this article showed one bug in CXF, which is being fixed. This bug causes the UsernamePolicy to be ignored unless some other form of security processing is also required by the policy. It's hard to judge the robustness of the CXF WS-SecurityPolicy handling based on the simple examples used in this article, but the design seems sound and it's likely that as more people make use of this relatively new feature of CXF, any quirks in the implementation will be resolved quickly.

The next Java Web services installment continues with CXF, this time looking at performance. See how CXF performance compares to the latest Axis2 and Metro releases, both for simple message exchanges and with WS-Security in use.

jieforest

源码下载

chszs

Good article.

justforregister

nice job

justforregister

没空学