Red Hat DocumentationFuse ESBToggle FramesPrintFeedback

Configure the Server-Side Interceptor


This section describes how to customize the server configuration, so that it is capable of checking and confirming the signature that appears in the SAML tokens received from the client.

Auto-installation of WSS4J interceptors

The underlying implementation of WS-Security and WS-Trust is provided by a set of WSS4J interceptors, based on the open source Apache WSS4J security toolkit. These interceptors are automatically installed into a server endpoint, if the endpoint is associated with a WS-SecurityPolicy policy in the server's WSDL file. In the absence of WSDL policies, it is also possible to install the WSS4J interceptors explicitly—see the WS-Security page.

Confirming the SAML token signature

In this example, the SAML token issued by the STS is signed by the STS certificate. The issued SAML token also declares the subject confirmation method to be bearer, which implies that the server should trust the bearer of the SAML token, only if the token's signature is confirmed.

Hence, the server must be configured so that it can confirm incoming signatures. The details of this type of configuration are given in Providing Encryption Keys and Signing Keys and, essentially, it consists of setting the property in the relevant jaxws:endpoint element. Confusingly, although this property is named encryption, it is also used for confirming signatures. The property accesses the STS certificate, which is used to confirm the token's signature.

Limitations of the server implementation

Because the current example is intended mainly to illustrate how to integrate a client with WS-Trust, the server side has not been fully implemented. Although the server (as configured here) is capable of understanding and processing security headers from the client, the server is not properly configured to enforce any authentication or authorization policies. In particular, if a client fails to send an authentication token, the server will happily process the request in any case.

A properly implemented server would be augmented by policies that require a particular kind of authentication token and the server would check the value of the received token, as appropriate.

Steps to configure the server-side interceptor

Perform the following steps to configure the server-side interceptor:

  1. Comment out the Java code for instantiating the Web service endpoint (in this example, it is more convenient to instantiate the endpoint in XML, because it enables you to specify all of the endpoint's properties in one place).

    Edit the file from the wsdl_first_https/src/demo/hw_https/server directory. Look for the lines of Java code that instantiate the Web service endpoint (highlighted below) and enclose them between /* and */, so that the lines are commented out as shown.

    package demo.hw_https.server;
    public class Server {
        protected Server() throws Exception {
            System.out.println("Starting Server");
            SpringBusFactory bf = new SpringBusFactory();
            URL busFile = Server.class.getResource("CherryServer.xml");
            Bus bus = bf.createBus(busFile.toString());
            Object implementor = new GreeterImpl();
            String address = "https://localhost:9001/SoapContext/SoapPort";
            Endpoint.publish(address, implementor);
  2. Create the Web service endpoint in XML. Edit the CherryServer.xml file from the wsdl_first_https/src/demo/hw_https/server directory. Add the following jaxws:endpoint element as a child of the beans element to instantiate the Web service endpoint.

    <beans ...>
      <jaxws:endpoint id="server"
        xmlns:s="" >
            <entry key="" value="sts/" />

    Notice how the wsdlLocation attribute points at the hello_world_server.wsdl file, which is the copy of the WSDL contract that excludes the IssuedToken policy. The property points at the file, sts/, which will be defined in a later step.

  3. Enable policy support and logging as follows. Continue editing the CherryServer.xml file. Add the following cxf:bus element as a child of the beans element:

    <beans ...>
      <cxf:bus xmlns:cxf="">
            <p:policies xmlns:p=""/>
  4. Add the requisite XML schema locations. Continue editing the CherryServer.xml file. To support the jaxws and cxf namespace prefixes, add the highlighted schema locations and define the jaxws namespace prefix, as follows:

    <beans xmlns=""
  5. Now define the file, which specifies the WSS4J properties for accessing the STS certificate. In the wsdl_first_https/sts directory, use your favorite text editor to create the file,, containing the following property settings:

    For more details on these WSS4J properties, see Providing Encryption Keys and Signing Keys.

  6. Add Maven instructions to copy the file into the target/classes/sts directory (so that the file gets included in the WAR package). Edit the pom.xml file from the wsdl_first_https/ directory and search for the copyxmlfiles target of the Maven antrun plug-in. Under configuration tasks, add the highlighted lines as shown in the following fragment:

    <project ...>
                                    <copy file="${basedir}/src/demo/hw_https/server/CherryServer.xml" todir="${basedir}/target/classes/demo/hw_https/server" />
                                    <copy file="${basedir}/src/demo/hw_https/client/WibbleClient.xml" todir="${basedir}/target/classes/demo/hw_https/client" />
                                    <copy file="${basedir}/src/demo/hw_https/client/InsecureClient.xml" todir="${basedir}/target/classes/demo/hw_https/client" />
                                    <copy todir="${basedir}/target/classes/certs">
                                        <fileset dir="${basedir}/certs" />
                                    <copy todir="${basedir}/target/classes/sts">
                                        <fileset dir="${basedir}/sts" />


    This step is only necessary, because this wsdl_first_https Maven project is set up in a slightly unconventional way. Normally, in a Maven project, you put all of your resource files under src/main/resources/, which Maven automatically copies into the target package.

Comments powered by Disqus