Latest Activity

Talend Application Integration Seminar Wednesday 6/22 in Arlington, Virginia

Glen Mazza - Sun, 06/19/2011 - 13:00

Talend's Hadrian Zbarcea will be giving a free seminar this Wednesday, June 22nd from 9am - 1pm at the Westin Arlington Gateway (two blocks from the orange line Ballston Metro Station). Description given:

Where On-Premise Applications Meet the Cloud: Addressing Cloud Integration Challenges with Apache Open Source Projects

While deploying applications in the cloud provides invaluable benefits of flexibility, fast provisioning, elasticity, and low overhead, pure public or private cloud deployments are few and far between. Traditional enterprise applications and databases continue to play mission-critical roles. For organizations with a combination of enterprise applications and SaaS-based IT environments, it is even harder to get application and data integration right. Concerns like latency, bandwidth, provisioning, permissions and security complicate integration in new ways.

Join us in this live seminar to learn how to address on-premise and cloud integration challenges:

  • Hear from open source integration experts like PMC Chair of the Apache Camel project Hadrian Zbarcea.
  • See a live demonstration of Apache CXF, Apache Camel and Apache ActiveMQ.
  • Engage experts in a panel discussion on how to tap into the value of open source integration.

If you're in the National Capital Area, register today!


Selenium Maven Plugin upgrade to Selenium Server 2.x

Olivier Lamy - Fri, 06/17/2011 - 10:50
The current selenium-maven-plugin from Codehaus Mojo has been updated to use selenium server 2.0rc2. So you will be able to use now selenium 2.x feature.
The Mojo version has been upgraded to 2.0-SNAPSHOT.
So feel free to test and report any issue.
To test it :
Add the codehaus snapshot repo in your pom :


Configure the mojo version


So have Fun.

Categories: Olivier Lamy

Failover support for CXF JAX-RS clients

Sergey Beryozkin - Thu, 06/16/2011 - 12:43
You may recall all those discussions about "RESTful services can be consumed from browsers by humans only" statements. It was awhile back and of course it's been proven since then that it's possible to write a sophisticated client code consuming RESTful services in a number of ways.

In JAX-RS land, Paul Santoz innovated with introducing the fluent API with all/most JAX-RS stacks having custom implementations, and this API is now being standardized by JSR-339 expert group. Proxy based API is also supported by some stacks.

What is important to realize now is that JAX-RS client runtimes need to become more robust and sophisticated in order to move further, beyond supporting the assertion that "yes, we can do it, we can write the client code for working with RESTful services".

A human working with the browser has more space as far as time and decision making is concerned, when facing a connection failure for example. On the other hand, the code needs to be smarter and ready if the expectations that it does not exit immediately after a connection has become slow, broken or a target endpoint has been recycled is to be met.

This is where a failover feature comes in and it's been supported for CXF JAX-WS clients for a long time. Starting from CXF 2.4.1 it's also the case for CXF JAX-RS clients.

Please check this page for more info, experiment and provide the feedback.

It also confirms that in CXF we are committed to bringing the best support for developing SOAP and REST services. SOAP and REST developers have their 'differences' :-) but we understand them, bring both 'camps' together, and do our best to support them at the framework level.

As a side note, if you think about it, making clients failover-capable is a cheap way toward ensuring something close to 24-7 up time. If you are Amazon or BBC then you have all the hardware and experience in place to ensure the clients nearly never experience a "can't connect" problem. What if you are running an OSGI container hosting service endpoints and need to replace a service ?

Failover-enabling clients is a simple way toward making service endpoints replaceable without affecting the critical client code being executed somewhere. Configuring a CXF failover feature with a small timeout between retries will do the trick really well.

One thing which is really exciting for me is that my Talend colleagues are already working on providing enterprise-level failover-like features for CXF JAX-RS clients and I'm going to talk about it in one of the future posts.

If you have already integrated CXF JAX-RS in your higher-level product then I'd encourage you to follow Talend's lead.
Categories: Sergey Beryozkin

WS-SecurityPolicy/SAML sample in Talend Service Factory 2.4.0

Colm O hEigeartaigh - Fri, 06/10/2011 - 23:05
In this post I will walk through the WS-SecurityPolicy sample that ships with Talend Service Factory 2.4.0. This sample shows how to secure a web service provider using both a UsernameToken and a SAML Assertion. For this post I will concentrate exclusively on the SAML case.

1) Download the artifacts

Go here and download Talend Service Factory 2.4.0. When this is done, go here and download the Talend Service Factory 2.4.0 examples (registration required). Extract the examples into the Talend Service Factory (TSF) install directory ($TSF_HOME). Finally, this sample requires that unlimited strength security policies be installed in the JDK.

2) Build and run the sample

Go to $TSF_HOME/examples/jaxws-ws-secpol and start with the README.txt. Run "mvn eclipse:eclipse" to generate eclipse projects, and "mvn install" to build and install the various modules. There are two options to run the sample.

2.1) Run the sample using maven

To start the service go to the service folder, and run "mvn exec:java". To run the test then go to the client folder and also run "mvn exec:java".

2.2) Run the sample in Karaf

To deploy the service and run the client in an OSGi environment, we can take advantage of the Karaf distribution that ships with TSF. Go to $TSF_HOME/container/bin and run the "karaf" binary. Install the three bundles in Karaf with:
  • install mvn:com.talend.sf.examples.jaxws-ws-secpol/ws-secpol-common/1.0
  • install mvn:com.talend.sf.examples.jaxws-ws-secpol/ws-secpol-server/1.0
  • install mvn:com.talend.sf.examples.jaxws-ws-secpol/ws-secpol-client/1.0
Each of these commands will print out a bundle id. Run the sample by invoking "start <id>" for each of the three bundle ids in turn.

3) The Service Provider

3.1) The Security Policy

The Service endpoint is secured via the following security policy fragment, which is defined in the WSDL ("ws-secpol-wsdl/greeter.wsdl" in the common folder):

  <sp:AsymmetricBinding xmlns:sp=".../ws-securitypolicy/200702">
          <sp:X509Token sp:IncludeToken=".../AlwaysToRecipient">
              <sp:RequireThumbprintReference />
              <sp:WssX509V3Token10 />
          <sp:X509Token sp:IncludeToken=".../Never">
              <sp:RequireThumbprintReference />
              <sp:WssX509V3Token10 />
  <sp:SignedSupportingTokens xmlns:sp=".../ws-securitypolicy/200702">
      <sp:SamlToken sp:IncludeToken=".../AlwaysToRecipient">

This Security Policy defines that the Asymmetric Binding is to be used in communication with the service provider, i.e. that the client must sign the request using its private key, and include the corresponding X509 Certificate in the security header of the request, and encrypt the request using the public key of the service provider. Authentication is performed on the basis of trust verification of the client's certificate, as the client illustrates proof-of-possession by signing some part of the request.

In addition to the Asymmetric Binding, the policy requires that a SAML 2.0 Assertion must be included in the service request, and it must be signed by the signature defined by the Asymmetric Binding policy. The (policy-driven) ability to add a SAML Assertion to a SOAP Request is new to Apache CXF 2.4.

Finally, the WSDL defines input and output policies (not included here), which specify that the SOAP Body must be signed and encrypted, and that all of the addressing headers must be signed if present.

3.2) The configuration

The standalone (maven-driven) case is configured entirely in code. The various security configuration items are added as properties to the JAX-WS Endpoint object. The same security configuration items are also used for the case of deploying the service provider in Karaf, except that it is all driven through spring, e.g.:

<jaxws:server id="SAMLGreeter" xmlns:ns1="..."
    <entry key="ws-security.callback-handler" value="..."/>
    <entry key="" value="..."/>
    <entry key="" value="..."/>
    <entry key="ws-security.saml2.validator" value="..."/>

Four security-related configuration options are used for the service provider. "ws-security.callback-handler" points to a CallbackHandler implementation that is used to supply a password for extracting a private key from a keystore to decrypt the request and sign the response. "" refers to a properties file which contains configuration options for loading the keystore used for encryption. Similarly, "" refers to a properties file for signature creation (and decryption).

"ws-security.saml2.validator" is a configuration tag new to CXF 2.4, and refers to an instance of the WSS4J Validator interface. The Validator interface is used in WSS4J to validate received security tokens. In this case, we are extending the default SAML2 Token Validation with a custom Validator. This Validator does some additional verification on the received token, namely checking who the issuer is, checking that the confirmation method is "sender-vouches", and checking that the Assertion contains an AttributeStatement, with an Attribute "attribute-role" containing a value "authenticated-client".

All of these configuration tags are defined in the SecurityConstants class in CXF.

4) The client

When the client wants to invoke on the service provider, it parses the security policy described above in the WSDL. As with the service provider, the client standalone case is configured entirely in code. For the case of deploying the client in Karaf, it is configured in spring as follows: 

<jaxws:client id="samlgreeter" wsdlLocation="..." serviceClass="..."
  xmlns:ns1="" serviceName="ns1:SecureGreeterService"
    <entry key="ws-security.signature.username" value="..."/>
    <entry key="ws-security.encryption.username" value="..."/>
    <entry key="ws-security.callback-handler"><bean class="..."/></entry>
    <entry key="" value="..."/>
    <entry key="" value="..."/>
    <entry key="ws-security.saml-callback-handler" value="..."/>

"ws-security.callback-handler", "" and "" have been covered in the section on configuring the service provider. "ws-security.signature.username" refers to the keystore alias of the private key to use to sign the request, and "ws-security.encryption.username" refers to the keystore alias to use to encrypt the request.

"ws-security.saml-callback-handler" is a configuration tag new to CXF 2.4, and refers to a CallbackHandler which will supply WSS4J with the information to create a SAML Assertion. This sample ships with a CallbackHandler that creates a simple SAML 2.0 Assertion with a subject confirmation method of "sender-vouches". It adds an Attribute to the Assertion that conveys to the Web Service Provider that the client has authenticated an external user in some way (not shown as part of this sample), and has assigned the attribute role of "authenticated-client" to the external user. The assertion that will be generated from this CallbackHandler instance will be signed by the client, as per the policy definition ("SignedSupportingTokens").

5) The Client Request

The security header of the client request contains a BinarySecurityToken which contains the certificate to use to verify the signature. It also contains a Timestamp, an EncryptedKey which is used to encrypt the SOAP Body, a SAML2 Assertion, and a Signature which signs the Timestamp, Assertion and encrypted SOAP Body. The Assertion looks like this:

<saml2:Assertion xmlns:saml2="..." xmlns:xsi="..." ID="..." IssueInstant="..."
  Version="2.0" xsi:type="saml2:AssertionType">
   <saml2:NameID Format=...:unspecified">uid=auth_client</saml2:NameID>
   <saml2:SubjectConfirmation Method="...:sender-vouches">
 <saml2:Conditions NotBefore="..." NotOnOrAfter="..."/>
   <saml2:Attribute FriendlyName="attribute-role" NameFormat="...">
     <saml2:AttributeValue xsi:type="xs:string">

The service provider processes the received security header as follows:
  1. It checks that the Timestamp is valid
  2. It uses its private key to decrypt the EncryptedKey, and then uses the decrypted key to decrypt the SOAP Body.
  3. It verifies that the Assertion is valid, and passes the Assertion to the custom Validator defined above to validate the contents of the Assertion.
  4. It verifies that the certificate defined in the BinarySecurityToken can validate the signature, verifies trust in the certificate, and checks that each of the References of the signature produce the correct digest.
At this point security processing is complete, and the service provider constructs a secured response to the client.
Categories: Colm O hEigeartaigh

WSS4J 1.6.1 released

Colm O hEigeartaigh - Wed, 06/08/2011 - 15:11
Apache WSS4J 1.6.1 has been released. The distribution can be downloaded here, and the list of issues that have been fixed is here. There are a number of bug fixes to the new functionality introduced in the 1.6.0 release, including some fixes to the SAML Assertion creation code, and a fix to get WSS4J 1.6 working with the IBM JDK. A noteworthy new feature is support for CRLs, as documented by a previous blog post.

In other news, my employer has published a short questionnaire to find out what topics users of open-source integration software are interested in learning about. So for example if you are interested in hearing more from me on enabling security in Apache CXF, navigate to the CXF part of the survey and select the appropriate checkbox for "WS-Security in Apache CXF".
Categories: Colm O hEigeartaigh

Using CXF's STSClient with a Metro STS

Glen Mazza - Tue, 06/07/2011 - 13:00

Thanks to Colm's programming efforts, versions 2.4.1 onward of Apache CXF are now able to work with Metro STSs, from both a CXF web service client (WSC) and web service provider (WSP) perspective. CXF's STSClient object handles this functionality for both the WSC and WSP. This blog entry lists the modifications needed to last week's Metro STS tutorial to use a CXF WSC and WSP instead of their Metro counterparts. The finished source code is available here. Of course don't use the provided keys in production and note the information within this tutorial may have errors within it, so be sure to carefully check all work before moving to production.

Note: Talend Services Factory's jaxws-ws-trust example also shows CXF's STSClient in use, also check CXF's sts_issue_operation sample contributed by the Talend team.

Customizations necessary for working with CXF:

  1. In Step #2 of the tutorial, the following dependencies to the CXF section of the parent POM (DoubleIt/pom.xml) needs to be added. These dependencies are used in reading and processing the WS-Policy statements in the STS and WSP WSDLs.

    <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-ws-security</artifactId> <version>${cxf.version}</version> </dependency> <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-ws-policy</artifactId> <version>${cxf.version}</version> </dependency>
  2. In Step #5, Substep #2 of the tutorial, we will need to add the following Metro dependencies to the sts-war submodule's pom.xml file.

    <repositories> <repository> <id></id> <name> Maven2 Repository for Metro</name> <url></url> </repository> </repositories> <dependencies> <dependency> <groupId>org.glassfish.metro</groupId> <artifactId>webservices-rt</artifactId> <version>2.1</version> </dependency> </dependencies>

    Also, we need to move the CXF dependencies from the top-level POM to the service submodule, because the Metro STS doesn't use the CXF dependencies. (It is not necessary to also declare the CXF dependencies in the client submodule, because the client already has a dependency on part of the service submodule and hence pulls the service's dependencies in.)

  3. For Step #6 of the tutorial (WSP creation), copy the updated DoubleIt.wsdl file to the service submodule just as is explained for the Metro WSP. However, remove the sc:KeyStore and sc:TrustStore elements from the WSDL, as CXF does such configuration in separate files instead.

    Other changes needed:

    • In the resources folder of the service submodule, create the following file:
    • Move the servicestore.jks file to the same resources folder.

    • We'll need a class to return the private key password when needed by the WSP. Place the following file in the same directory as the WSP's DoubleItPortTypeImpl class:

      package service; import; import java.util.HashMap; import java.util.Map; import; import; import; import; public class ServiceKeystorePasswordCallback implements CallbackHandler { private Map passwords = new HashMap(); public ServiceKeystorePasswordCallback() { passwords.put("myservicekey", "skpass"); } public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException { for (int i = 0; i < callbacks.length; i++) { WSPasswordCallback pc = (WSPasswordCallback)callbacks[i]; String pass = (String) passwords.get(pc.getIdentifier()); if (pass != null) { pc.setPassword(pass); return; } } } }
    • Moving now to the war submodule, alter the cxf-servlet.xml to link the file to the WSP:

      <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="" xmlns:xsi="" xmlns:jaxws="" xmlns:soap="" xsi:schemaLocation=""> <jaxws:endpoint id="doubleit" implementor="service.DoubleItPortTypeImpl" wsdlLocation="WEB-INF/wsdl/DoubleIt.wsdl" address="/doubleit"> <jaxws:properties> <entry key="ws-security.callback-handler" value="service.ServiceKeystorePasswordCallback"/> <entry key="" value=""/> <entry key="" value="false"/> </jaxws:properties> </jaxws:endpoint> </beans>

    As discussed in Step #6 in the original tutorial, make sure you can see the WSP's WSDL from a browser before proceeding to the next section.

  4. Ignore the entire Step #7 of the tutorial (WSC creation), as none of it is relevant for CXF clients. Instead, the following files will need to be added to the CXF client module:

    • In the client package, create the following password callback handler, used to provide both the password for the "alice" user and that of the private key password for signing/decryption:

      package client; import; import; import; import; import; public class UTCallbackHandler implements CallbackHandler { public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException { for (int i = 0; i < callbacks.length; i++) { if (callbacks[i] instanceof WSPasswordCallback) { // CXF WSPasswordCallback pc = (WSPasswordCallback) callbacks[i]; if ("myclientkey".equals(pc.getIdentifier())) { pc.setPassword("ckpass"); break; } else { pc.setPassword("clarinet"); break; } } } } }
    • In the client submodule's resources folder, create the following file:
    • Move the clientstore.jks keystore to the client submodule's resources folder.

    • Also in the resources folder, the following cxf.xml file needs to be created. It provides the encryption and UsernameToken information necessary for communication between the WSC and the STS.

      <beans xmlns="" xmlns:xsi="" xmlns:jaxws="" xmlns:cxf="" xsi:schemaLocation=""> <jaxws:client name="{}DoubleItPort" createdFromAPI="true"> <jaxws:properties> <entry key="ws-security.sts.client"> <bean class=""> <constructor-arg ref="cxf"/> <property name="wsdlLocation" value="DoubleItSTSService.wsdl"/> <property name="serviceName" value="{}DoubleItSTSService"/> <property name="endpointName" value="{}IDoubleItSTSService_Port"/> <property name="properties"> <map> <entry key="ws-security.username" value="alice"/> <entry key="ws-security.callback-handler" value="client.UTCallbackHandler"/> <entry key="" value=""/> <entry key="ws-security.encryption.username" value="mystskey"/> <entry key="" value="false"/> </map> </property> </bean> </entry> </jaxws:properties> </jaxws:client> </beans>
    • The DoubleItSTSService.wsdl and sts_schema.xsd files from the sts-war submodule will need to be copied into the client's resources folder. After copying over, remove the STS KeyStore, TrustStore, ValidatorConfiguration, and STSConfiguration elements from the client's copy of the WSDL. At this stage, you should be able to successfully run the CXF client as shown in Step #8 of the Metro STS tutorial.


Learn about major Apache projects with Talend

Sergey Beryozkin - Mon, 06/06/2011 - 17:09
Talend Application Integration Division team is working on organizing 1 or 2 day courses designed to provide developers with free, hands-on training on Apache CXF, Apache Karaf, Apache Camel and Apache ActiveMQ projects.

Talend will organize the training days in locations where a reasonable number of people can attend.

Please take this 5 min survey and start looking forward to meeting Talend in your local area :)
Categories: Sergey Beryozkin

Talend Links (5 June 2011)

Glen Mazza - Sun, 06/05/2011 - 13:00

What do you want me to talk about?

Daniel Kulp - Thu, 06/02/2011 - 15:17
Talend is conducting a survey to help prioritize various topics people might be interesting in learning about relating to the Apache projects that we support and participate in. This is a great opportunity for people to let us know where you think we need to provide better documentation, official training, webinars, etc… to help people [...]
Categories: Daniel Kulp

Deploying and Using a Metro Security Token Service (STS)

Glen Mazza - Tue, 05/31/2011 - 13:00

In this tutorial we'll be creating a Metro Secure Token Service (STS) and show how to access the STS using either a Metro or CXF web service client (WSC). The clients will access the Metro STS to obtain SAML tokens that will subsequently be used to authenticate/authorize SOAP requests to Metro or CXF web service providers (WSP's) that trust the STS. This process shifts the validation of the client from the web service provider to the STS, meaning that the web service provider would not need to be individually configured to trust each client accessing it. All that is required is that there be a trust relationship between the WSC and the STS, and between the WSP and the STS. (The links at the bottom of this tutorial provide more information on the Metro STS and STSs in general.)

As usual, we'll rely on the sample DoubleIt web service provider and client as the starting basis for our work (For this example, I'm changing the Maven groupId and artifactId of the top-level pom to and metrosts-sample-metro, respectively.) The downloadable source code uses a Metro WSC and WSP; see this blog entry for the changes needed to the below for using a CXF WSC and WSP instead. Note the information within this tutorial is provided "as is" and may have errors within it, be sure to carefully check all work before moving to production with any of this information.

Steps involved for hosting a Metro-based STS on Tomcat:

  1. Update your JDK's JAX-WS and JAXB libraries. Before being deployed on Tomcat, the Metro STS requires the newer 2.2.x versions of JAX-WS and JAXB not provided by default in Java SE 6. See here for more information on placing these new JARs in your JDK's endorsed folder.

  2. Run the DoubleIt web service and SOAP client. Follow the DoubleIt tutorial and run either the Metro or CXF versions of the WSP and WSC. (Metro WSP and WSC's are explained below; see the Talend links at the top for CXF WSP and WSC configuration.) Confirm that SOAP calls between the WSC and WSP are working before proceeding.

  3. Create keystores for the client, service, and STS. Note that the keys here are not meant for production use--they are self-signed and naturally should have passwords different from the ones I'm publishing below. Create the service and client keystores as shown in Step #1 in the OpenSSL tutorial. Also create the STS keystore as follows:

    openssl req -x509 -days 3650 -newkey rsa:1024 -keyout stskey.pem -out stscert.pem -passout pass:stsspass

    openssl pkcs12 -export -inkey stskey.pem -in stscert.pem -out sts.p12 -name mystskey -passin pass:stsspass -passout pass:stskpass

    keytool -importkeystore -destkeystore stsstore.jks -deststorepass stsspass -srckeystore sts.p12 -srcstorepass stskpass -srcstoretype pkcs12

    keytool -list -keystore stsstore.jks -storepass stsspass

    keytool -exportcert -alias mystskey -storepass stsspass -keystore stsstore.jks -file sts.cer

    keytool -printcert -file sts.cer

    rm *.pem *.p12

    For tutorial purposes place the keys immediately under the DoubleIt project folder. By default Metro hardcodes a fixed path to the keystore and truststore locations within the WSDLs, causing portability problems should you move the example from one computer to another. To fix this, the source code download uses Maven resource filtering to allow for a relative path to the project base directory to be used instead.

    Next, the service keystore will need to have the STS public key added so it trusts it, and vice-versa. Also, the client will need to have the STS' and WSP's certificates added to its truststore, as it relies on symmetric binding to encrypt the SOAP requests it makes to both:

    keytool -keystore servicestore.jks -storepass sspass -import -noprompt -trustcacerts -alias mystskey -file sts.cer

    keytool -keystore stsstore.jks -storepass stsspass -import -noprompt -trustcacerts -alias myservicekey -file service.cer

    keytool -keystore clientstore.jks -storepass cspass -import -noprompt -trustcacerts -alias mystskey -file sts.cer

    keytool -keystore clientstore.jks -storepass cspass -import -noprompt -trustcacerts -alias myservicekey -file service.cer

    Since the service does not directly trust the client (the purpose for our use of the STS to begin with), we will not add the client's public certificate to the service's truststore as normally done with message-layer encryption.

  4. Use NetBeans to create a Secure Token Service for issuing SAML tokens. I'm using NB 7.0 with the GlassFish 3.1 server, even though I'll be deploying on a Tomcat 7.x server. (The Netbeans STS wizard requires the GlassFish server when creating the STS, even though it will work on Tomcat deployment.) The Netbeans installation process allows you to install GlassFish and/or Tomcat during the IDE install, if necessary for your machine.

    Follow the section To Create a Third-Party STS in the Metro Users' Guide for this step, adding in the following changes:

    • For Step #3, I used "DoubleItSTS" for the project name. On the Server page, choose the GlassFish 3.1 server and Java EE 6 Web (or Java EE 5 if you plan on installing on Tomcat 6).
    • For Steps #8 and #9, I used DoubleItSTS as the class name and sts as the package name, and Version Compatibility of .NET 3.5 / Metro 1.3.
    • For Step #15, I'm using the "Username Authentication with Symmetric Key" security mechanism with Username authentication token (If desired, select the Configure... button to configure X.509 authentication token instead. If you choose this option you'll need to add the client's public key to the STS keystore.)
    • For Step #16, I chose Basic 256-bit encryption, however that will require installing JCE Unlimited Strength on your JRE if you haven't already--follow the README in this download for more information.
    • For Step #17, Use DoubleItSTSIssuer for the issuer name, and delete the default service provider and create a new one with these values:

      • Provider Endpoint URI: http://localhost:8080/doubleit/services/doubleit
      • Certificate Alias: myservicekey
      • Token Type: 1.1
      • Key Type: Public Key

      An STS can provide SAML tokens for multiple service providers. The STS uses each service provider entry to determine the key to use to encrypt the SAML token. Also, if configured, the STS can customize the data the SAML token returns to each service to account for that service's specific needs.

    • For Step #20, use the STS keystore you created in the previous step. Also:
      1. Configure the truststore to use the STS keystore (the STS will use the public key entries in the keystore.)
      2. If you're using UsernameToken for WSC->STS authentication, click the "Validators..." button and set the Username Validator field to sts.PlainTextPasswordValidator. Also, copy the PlainTextPasswordValidator class from the Metro UsernameToken tutorial and place it in the same sts package as the DoubleItSTS class. This class will handle the UsernameToken validation from the client to the STS.
    • For Step #21, the relative URL will be /DoubleItSTSService?wsdl
    • For Step #22, before running the STS on the GlassFish server, due to apparent generation bugs with the IDE's wizards we'll need to make a couple of corrections to the files it generates:
      1. In the DoubleItSTS/Web Pages/WEB-INF/web.xml file, add the following context listener and change the servlet-class entries for the DoubleItSTS and MEX endpoints to as shown: <listener> <listener-class> </listener-class> </listener> ... <servlet> <servlet-name>com.mycompany.webservice.sts.DoubleItSTS</servlet-name> <servlet-class></servlet-class> <load-on-startup>0</load-on-startup> </servlet> <servlet> <servlet-name></servlet-name> <servlet-class></servlet-class> <load-on-startup>0</load-on-startup> </servlet> ...
      2. In the sun-jaxws.xml file in the same directory, add an entry for the STS below the one for the MEX endpoint: <endpoint implementation="...MEXEndpoint" ... <endpoint name="DoubleItSTS Implementation" implementation="sts.DoubleItSTS" wsdl="WEB-INF/wsdl/DoubleItSTS/DoubleItSTSService.wsdl" url-pattern="/DoubleItSTSService"/>

    Before proceeding to the next step, make sure you can see the WSDL on the GlassFish server at http://localhost:8080/DoubleItSTS/DoubleItSTSService?wsdl.

  5. Merge the NetBeans-created STS into the Mavenized DoubleIt Project. We'll be leaving Netbeans and GlassFish now and moving back to Tomcat and our Mavenized DoubleIt project. Steps:

    1. In the DoubleIt folder, create a sts-war directory alongside the currently existing service, war, and client folders. Add the following folders underneath sts-war: for Linux: mkdir -p sts-war/src/main/java/sts mkdir -p sts-war/src/main/resources mkdir -p sts-war/src/main/webapp/WEB-INF/wsdl mkdir -p sts-war/src/main/webapp/WEB-INF/lib for Windows: mkdir sts-war\src\main\java\sts mkdir sts-war\src\main\resources mkdir sts-war\src\main\webapp\WEB-INF\wsdl mkdir sts-war\src\main\webapp\WEB-INF\lib
    2. Add the following pom.xml file to the sts-war directory.
    3. <project xmlns="" xmlns:xsi="" xsi:schemaLocation=""> <modelVersion>4.0.0</modelVersion> <parent> <groupId></groupId> <artifactId>metrosts-sample-metro</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>sts-war</artifactId> <name>Metro STS</name> <packaging>war</packaging> <!-- Metro WSDL files contain hardcoded keystore config location info Below constant filtered (inserted) by Maven into those files for portability --> <properties> <keystore.dir>${basedir}/..</keystore.dir> </properties> <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>tomcat-maven-plugin</artifactId> <version>1.1</version> <configuration> <server>myTomcat</server> <url>http://localhost:8080/manager/text</url> <path>/${}</path> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>2.1.1</version> <configuration> <webResources> <resource> <directory>src/main/webapp</directory> <filtering>true</filtering> </resource> </webResources> </configuration> </plugin> </plugins> <!-- Name of the generated WAR file --> <finalName>DoubleItSTS</finalName> </build> </project>

      You will also need to add this new module to the parent DoubleIt/pom.xml file:

      <modules> <module>service</module> <module>war</module> <module>client</module> <module>sts-war</module> </modules>
    4. Copy the DoubleItSTSService.wsdl and sts_schema.xsd files from NetBeans (located in the {user home directory}/NetBeansProjects/DoubleItSTS/src/conf/xml-resources/web-services/DoubleItSTS/wsdl) to the WEB-INF/wsdl folder of the DoubleIt sts-war project. The WSDL that NetBeans generated for me as of this writing is below, but you'll want to rely on your WSDL which includes the specific security settings that you added in. To help in understanding the security elements, I added hyperlinks to several of the policy elements in the WSDL to their definitions in various specifications.

      DoubleItSTSService.wsdl: <?xml version="1.0" encoding="utf-8"?> <!-- DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER. Copyright 1997-2010 Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. The contents of this file are subject to the terms of either the GNU General Public License Version 2 only ("GPL") or the Common Development and Distribution License("CDDL") (collectively, the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the License at or nbbuild/licenses/CDDL-GPL-2-CP. See the License for the specific language governing permissions and limitations under the License. When distributing the software, include this License Header Notice in each file and include the License file at nbbuild/licenses/CDDL-GPL-2-CP. Oracle designates this particular file as subject to the "Classpath" exception as provided by Oracle in the GPL Version 2 section of the License file that accompanied this code. If applicable, add the following below the License Header, with the fields enclosed by brackets [] replaced by your own identifying information: "Portions Copyrighted [year] [name of copyright owner]" Contributor(s): The Original Software is NetBeans. The Initial Developer of the Original Software is Sun Microsystems, Inc. Portions Copyright 1997-2007 Sun Microsystems, Inc. All Rights Reserved. If you wish your version of this file to be governed by only the CDDL or only the GPL Version 2, indicate your decision by adding "[Contributor] elects to include this software in this distribution under the [CDDL or GPL Version 2] license." If you do not indicate a single choice of license, a recipient has the option to distribute your version of this file under either the CDDL, the GPL Version 2 or to extend the choice of license to its licensees as provided above. However, if you add GPL Version 2 code and therefore, elected the GPL Version 2 license, then the option applies only if the new code is made subject to such option by the copyright holder. --> <wsdl:definitions name="DoubleItSTSService" targetNamespace="" xmlns:wsdl="" xmlns:wsu="" xmlns:soapenc="" xmlns:wsam="" xmlns:i0="" xmlns:xsd="" xmlns:wsp="" xmlns:tns="" xmlns:soap="" xmlns:wsx="" xmlns:q1="" xmlns:q2="" xmlns:jaxws="" xmlns:wsa10="" xmlns="" xmlns:sp="" xmlns:sc="" xmlns:wspp=""> <wsp:Policy wsu:Id="IDoubleItSTSService_policy"> <wsp:ExactlyOne> <wsp:All> <sc:ValidatorConfiguration xmlns:sc=""> <sc:Validator name="usernameValidator" classname="sts.PlainTextPasswordValidator" /> </sc:ValidatorConfiguration> <tc:STSConfiguration xmlns:tc="" encryptIssuedKey="true" encryptIssuedToken="false"> <tc:LifeTime>36000</tc:LifeTime> <tc:Contract> </tc:Contract> <tc:Issuer>DoubleItSTSIssuer</tc:Issuer> <tc:ServiceProviders> <tc:ServiceProvider endpoint="http://localhost:8080/doubleit/services/doubleit"> <tc:CertAlias>myservicekey</tc:CertAlias> <tc:TokenType> </tc:TokenType> <tc:KeyType> </tc:KeyType> </tc:ServiceProvider> </tc:ServiceProviders> </tc:STSConfiguration> <wsam:Addressing wsp:Optional="false"> <wsp:Policy> <wsam:AnonymousResponses/> </wsp:Policy> </wsam:Addressing> <sp:SymmetricBinding> <wsp:Policy> <sp:ProtectionToken> <wsp:Policy> <sp:X509Token sp:IncludeToken=""> <wsp:Policy> <sp:WssX509V3Token10 /> <sp:RequireIssuerSerialReference /> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:ProtectionToken> <sp:Layout> <wsp:Policy> <sp:Strict /> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp /> <sp:OnlySignEntireHeadersAndBody /> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256 /> </wsp:Policy> </sp:AlgorithmSuite> </wsp:Policy> </sp:SymmetricBinding> <sp:Wss11> <wsp:Policy> <sp:MustSupportRefIssuerSerial/> <sp:MustSupportRefThumbprint /> <sp:MustSupportRefEncryptedKey /> </wsp:Policy> </sp:Wss11> <sp:SignedSupportingTokens> <wsp:Policy> <sp:UsernameToken sp:IncludeToken=""> <wsp:Policy> <sp:WssUsernameToken10 /> </wsp:Policy> </sp:UsernameToken> </wsp:Policy> </sp:SignedEncryptedSupportingTokens> <sc:KeyStore wspp:visibility="private" alias="mystskey" keypass="stskpass" storepass="stsspass" type="JKS" location="/home/gmazza/dataExt3/workspace/DoubleIt-Metro/stsstore.jks" /> <sc:TrustStore wspp:visibility="private" storepass="stsspass" type="JKS" location="/home/gmazza/dataExt3/workspace/DoubleIt-Metro/stsstore.jks" /> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> <wsdl:types> <xsd:schema targetNamespace=""> <xsd:import schemaLocation="sts_schema.xsd" namespace="" /> </xsd:schema> </wsdl:types> <wsdl:message name="IDoubleItSTSService_IssueToken_InputMessage"> <wsdl:part name="rstMessage" type="q1:MessageBody" /> </wsdl:message> <wsdl:message name="IDoubleItSTSService_IssueToken_OutputMessage"> <wsdl:part name="IssueTokenResult" type="q2:MessageBody" /> </wsdl:message> <wsdl:portType name="IDoubleItSTSService"> <wsdl:operation name="IssueToken"> <wsdl:input wsam:Action="" message="tns:IDoubleItSTSService_IssueToken_InputMessage" /> <wsdl:output wsam:Action="" message="tns:IDoubleItSTSService_IssueToken_OutputMessage" /> </wsdl:operation> </wsdl:portType> <wsdl:binding name="IDoubleItSTSService_Binding" type="tns:IDoubleItSTSService"> <wsp:PolicyReference URI="#IDoubleItSTSService_policy" /> <soap:binding transport="" /> <wsdl:operation name="IssueToken"> <soap:operation soapAction="" style="document" /> <wsdl:input> <soap:body use="literal" /> <wsp:PolicyReference URI="#IDoubleItSTSService_Binding_IssueToken_Input_Policy" /> </wsdl:input> <wsdl:output> <soap:body use="literal" /> <wsp:PolicyReference URI="#IDoubleItSTSService_Binding_IssueToken_Output_Policy" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="DoubleItSTSService"> <wsdl:port name="IDoubleItSTSService_Port" binding="tns:IDoubleItSTSService_Binding"> <soap:address location="http://localhost:8080/jaxws-sts/sts" /> <jaxws:bindings> <jaxws:provider>true</jaxws:provider> </jaxws:bindings> </wsdl:port> </wsdl:service> <wsp:Policy wsu:Id="IDoubleItSTSService_Binding_IssueToken_Input_Policy"> <wsp:ExactlyOne> <wsp:All> <sp:EncryptedParts> <sp:Body /> </sp:EncryptedParts> <sp:SignedParts> <sp:Body /> <sp:Header Name="To" Namespace="" /> <sp:Header Name="From" Namespace="" /> <sp:Header Name="FaultTo" Namespace="" /> <sp:Header Name="ReplyTo" Namespace="" /> <sp:Header Name="MessageID" Namespace="" /> <sp:Header Name="RelatesTo" Namespace="" /> <sp:Header Name="Action" Namespace="" /> <sp:Header Name="AckRequested" Namespace="" /> <sp:Header Name="SequenceAcknowledgement" Namespace="" /> <sp:Header Name="Sequence" Namespace="" /> <sp:Header Name="CreateSequence" Namespace="" /> </sp:SignedParts> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> <wsp:Policy wsu:Id="IDoubleItSTSService_Binding_IssueToken_Output_Policy"> <wsp:ExactlyOne> <wsp:All> <sp:EncryptedParts> <sp:Body /> </sp:EncryptedParts> <sp:SignedParts> <sp:Body /> <sp:Header Name="To" Namespace="" /> <sp:Header Name="From" Namespace="" /> <sp:Header Name="FaultTo" Namespace="" /> <sp:Header Name="ReplyTo" Namespace="" /> <sp:Header Name="MessageID" Namespace="" /> <sp:Header Name="RelatesTo" Namespace="" /> <sp:Header Name="Action" Namespace="" /> <sp:Header Name="AckRequested" Namespace="" /> <sp:Header Name="SequenceAcknowledgement" Namespace="" /> <sp:Header Name="Sequence" Namespace="" /> <sp:Header Name="CreateSequence" Namespace="" /> </sp:SignedParts> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> </wsdl:definitions> sts_schema.xsd: <?xml version="1.0" encoding="utf-8"?> <xs:schema elementFormDefault="qualified" targetNamespace="" xmlns:xs="" xmlns:tns=""> <xs:complexType name="MessageBody"> <xs:sequence> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any"/> </xs:sequence> </xs:complexType> </xs:schema>
    5. Copy the and files from the NetBeans project to the src/main/java/.../sts folder you created above. Also alter the wsdlLocation attribute of the WebServiceProvider annotation, removing the "DoubleItSTS" subfolder (if present), as this tutorial places the wsdl directly under WEB-INF/wsdl. As of this writing, the below is what the resulting NetBeans 7.0-generated class looks like:

      package sts; import javax.annotation.Resource; import javax.xml.transform.Source; import; import; import; import; import; import; /** * * @author gmazza */ @WebServiceProvider(serviceName = "DoubleItSTSService", portName = "IDoubleItSTSService_Port", targetNamespace = "", wsdlLocation = "WEB-INF/wsdl/DoubleItSTSService.wsdl") @ServiceMode(value = Mode.PAYLOAD) public class DoubleItSTS extends implements Provider { @Resource WebServiceContext context; public Source invoke(Source rstElement) { return super.invoke(rstElement); } protected MessageContext getMessageContext() { MessageContext msgCtx = context.getMessageContext(); return msgCtx; } }
    6. Copy the web.xml and sun-jaxws.xml files located in {user home directory}/NetBeansProjects/DoubleItSTS/web/WEB-INF/ to the sts-war/.../WEB-INF folder. In sun-jaxws.xml, remove the /DoubleItSTS/ subfolder from the wsdl attribute (it should just be WEB-INF/wsdl/DoubleItSTSService.wsdl.)
    7. Shut down the GlassFish server (Netbeans provides an "X" button in the server output window to do this) and start up Tomcat. From a command-line window in the sts-war folder, run mvn clean install tomcat:deploy. (See the DoubleIt tutorial for more on this command.) After deploying, make sure you can see the wsdl from a browser at localhost:8080/DoubleItSTS/DoubleItSTSService?wsdl before proceeding to the next step. You also may wish to take a look at the STS service listing page at http://localhost:8080/DoubleItSTS/DoubleItSTSService, but note that the MetadataExchange (MEX) endpoint hyperlinked on that page will not return a WSDL.
  6. Configure the web service provider to require the SAML tokens provided by the STS. Formal directions for doing so are here, but for this tutorial perhaps easier to follow Step #2 of the Metro UsernameToken tutorial for this process, with the following changes in substep #3:

    • For the Secure Service security mechanism, select STS Issued Token. Select the Configure button and enter the STS URL (http://localhost:8080/DoubleItSTS/DoubleItSTSService) and MetadataExchange URL (http://localhost:8080/DoubleItSTS/DoubleItSTSService/mex). As stated in Step #8 of the Metro guide, you'll need to use the same algorithm suite value that you configured above for the STS.
    • Unselect "Use Development Defaults". For the keystore, choose the servicestore.jks file created earlier, and enter the store password, alias (myservicekey), and key password. For truststore, enter the same keystore and keystore password.
    • Unselect Act As STS if selected. Select finish.

    The resulting service WSDL should look similar to the following. Make sure you copy your modified WSDL back to the Mavenized project (into the service/src/main/resources folder) as discussed in Step #2 of the UsernameToken tutorial:

    <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions name="DoubleIt" xmlns:xsd="" xmlns:wsdl="" xmlns:soap="" xmlns:di="" xmlns:tns="" targetNamespace="" xmlns:wsp="" xmlns:wsu="" xmlns:fi="" xmlns:tcp="" xmlns:wsam="" xmlns:sp="" xmlns:sc="" xmlns:wspp="" xmlns:t="" xmlns:wsaw="" xmlns:wsx=""> <wsdl:types> <xsd:schema targetNamespace=""> <xsd:element name="DoubleIt"> <xsd:complexType> <xsd:sequence> <xsd:element name="numberToDouble" type="xsd:int"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="DoubleItResponse"> <xsd:complexType> <xsd:sequence> <xsd:element name="doubledNumber" type="xsd:int" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> </wsdl:types> <wsdl:message name="DoubleItRequest"> <wsdl:part element="di:DoubleIt" name="parameters" /> </wsdl:message> <wsdl:message name="DoubleItResponse"> <wsdl:part element="di:DoubleItResponse" name="parameters" /> </wsdl:message> <wsdl:portType name="DoubleItPortType"> <wsdl:operation name="DoubleIt"> <wsdl:input message="tns:DoubleItRequest" /> <wsdl:output message="tns:DoubleItResponse" /> </wsdl:operation> </wsdl:portType> <wsdl:binding name="DoubleItBinding" type="tns:DoubleItPortType"> <wsp:PolicyReference URI="#DoubleItBindingPolicy"/> <soap:binding style="document" transport="" /> <wsdl:operation name="DoubleIt"> <soap:operation soapAction=""/> <wsdl:input><soap:body use="literal"/> <wsp:PolicyReference URI="#DoubleItBinding_DoubleIt_Input_Policy"/> </wsdl:input> <wsdl:output><soap:body use="literal"/> <wsp:PolicyReference URI="#DoubleItBinding_DoubleIt_Output_Policy"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="DoubleItService"> <wsdl:port name="DoubleItPort" binding="tns:DoubleItBinding"> <soap:address location="http://localhost:8080/doubleit/services/doubleit"/> </wsdl:port> </wsdl:service> <wsp:Policy wsu:Id="DoubleItBindingPolicy"> <wsp:ExactlyOne> <wsp:All> <wsam:Addressing wsp:Optional="false"/> <sp:SymmetricBinding> <wsp:Policy> <sp:ProtectionToken> <wsp:Policy> <sp:IssuedToken sp:IncludeToken=""> <sp:RequestSecurityTokenTemplate> <t:TokenType></t:TokenType> <t:KeyType></t:KeyType> <t:KeySize>256</t:KeySize> </sp:RequestSecurityTokenTemplate> <wsp:Policy> <sp:RequireInternalReference/> </wsp:Policy> <sp:Issuer> <wsaw:Address>http://localhost:8080/DoubleItSTS/DoubleItSTSService</wsaw:Address> <wsaw:Metadata> <wsx:Metadata> <wsx:MetadataSection> <wsx:MetadataReference> <wsaw:Address>http://localhost:8080/DoubleItSTS/DoubleItSTSService/mex</wsaw:Address> </wsx:MetadataReference> </wsx:MetadataSection> </wsx:Metadata> </wsaw:Metadata> </sp:Issuer> </sp:IssuedToken> </wsp:Policy> </sp:ProtectionToken> <sp:Layout> <wsp:Policy> <sp:Lax/> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp/> <sp:OnlySignEntireHeadersAndBody/> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256/> </wsp:Policy> </sp:AlgorithmSuite> </wsp:Policy> </sp:SymmetricBinding> <sp:Wss11> <wsp:Policy> <sp:MustSupportRefIssuerSerial/> <sp:MustSupportRefThumbprint/> <sp:MustSupportRefEncryptedKey/> </wsp:Policy> </sp:Wss11> <sp:Trust13> <wsp:Policy> <sp:MustSupportIssuedTokens/> <sp:RequireClientEntropy/> <sp:RequireServerEntropy/> </wsp:Policy> </sp:Trust13> <sc:KeyStore wspp:visibility="private" location="/work/workspace/DoubleItMetroWSTrust/servicestore.jks" type="JKS" storepass="sspass" alias="myservicekey" keypass="skpass"/> <sc:TrustStore wspp:visibility="private" storepass="sspass" type="JKS" location="/home/gmazza/workspace/DoubleItMetroWSTrust/servicestore.jks"/> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> <wsp:Policy wsu:Id="DoubleItBinding_DoubleIt_Input_Policy"> <wsp:ExactlyOne> <wsp:All> <sp:EncryptedParts> <sp:Body/> </sp:EncryptedParts> <sp:SignedParts> <sp:Body/> <sp:Header Name="To" Namespace=""/> <sp:Header Name="From" Namespace=""/> <sp:Header Name="FaultTo" Namespace=""/> <sp:Header Name="ReplyTo" Namespace=""/> <sp:Header Name="MessageID" Namespace=""/> <sp:Header Name="RelatesTo" Namespace=""/> <sp:Header Name="Action" Namespace=""/> <sp:Header Name="AckRequested" Namespace=""/> <sp:Header Name="SequenceAcknowledgement" Namespace=""/> <sp:Header Name="Sequence" Namespace=""/> <sp:Header Name="CreateSequence" Namespace=""/> </sp:SignedParts> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> <wsp:Policy wsu:Id="DoubleItBinding_DoubleIt_Output_Policy"> <wsp:ExactlyOne> <wsp:All> <sp:EncryptedParts> <sp:Body/> </sp:EncryptedParts> <sp:SignedParts> <sp:Body/> <sp:Header Name="To" Namespace=""/> <sp:Header Name="From" Namespace=""/> <sp:Header Name="FaultTo" Namespace=""/> <sp:Header Name="ReplyTo" Namespace=""/> <sp:Header Name="MessageID" Namespace=""/> <sp:Header Name="RelatesTo" Namespace=""/> <sp:Header Name="Action" Namespace=""/> <sp:Header Name="AckRequested" Namespace=""/> <sp:Header Name="SequenceAcknowledgement" Namespace=""/> <sp:Header Name="Sequence" Namespace=""/> <sp:Header Name="CreateSequence" Namespace=""/> </sp:SignedParts> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> </wsdl:definitions>

    Next, run mvn clean install from the DoubleIt folder and then mvn tomcat:redeploy from the war submodule. Make sure you view the WSP WSDL at http://localhost:8080/DoubleIt/services/DoubleIt?wsdl before continuing.

  7. Configure the SOAP client to use the STS to obtain the security token. SOAP Client configuration involves two steps: (1) configuring keystore and truststore information for interaction between the WSC and the STS and WSP, and (2) configuring the UsernameToken authentication information for the STS call. Formal directions for both are here, but you can refer to Step #4 and Step #5 of the Metro/Username Token tutorial for this step, except replace Substeps #3 and #4 of Step #4 with the following:

    Substep #3:

    • After selecting Edit Web Service Attributes, select the Keystore button and enter your clientstore.jks file location, storepassword, private key and private key password.
    • Select the Truststore button and choose the same clientstore.jks and keystore password as well as the service provider certificate within the truststore (myservicekey in this example). You will see the updated configuration information in Source the Packages/META-INF/DoubleIt.xml file created by NetBeans.
    • Do not enter username/password handler info or the callback classes in this step (between client and service); this will be done in the next section (between client and sts).
    • Select the Secure Token Service configuration at the bottom and supply http://localhost:8080/DoubleItSTS/DoubleItSTSService for the Endpoint value and 1.3 for the WS-Trust version. The defaults that Netbeans derives from the Endpoint address for the other fields (WSDL Location, Metadata, etc.) is sufficient for our needs and so can be left blank.

    The above process creates two client configuration files in Netbeans: Source Packages/META-INF/DoubleIt.xml and /wsit-client.xml.

    Substep #4:

    Before moving the configuration files back to your Maven project additional NetBeans configuration will be necessary for the call between the client and the STS, resulting in a third client configuration file, DoubleItSTSService.xml. Follow Steps #9-#14 in the Metro User's Guide here, except for Step #14, In the META-INF/DoubleItSTSService.xml file, we'll need to add the CallbackHandler configuration to the new configuration file as follows:

    <wsp:Policy wsu:Id="IDoubleItSTSService_BindingPolicy"> <wsp:ExactlyOne> <wsp:All> <sc1:KeyStore wspp:visibility="private" storepass="cspass" alias="myclientkey" keypass="ckpass" type="JKS" location="/home/gmazza/workspace/DoubleItMetroWSTrust/clientstore.jks"/> <sc1:TrustStore wspp:visibility="private" peeralias="mystskey" storepass="cspass" type="JKS" location="/home/gmazza/workspace/DoubleItMetroWSTrust/clientstore.jks"/> <sc1:CallbackHandlerConfiguration wspp:visibility="private"> <sc1:CallbackHandler default="alice" name="usernameHandler"/> <sc1:CallbackHandler default="clarinet" name="passwordHandler"/> </sc1:CallbackHandlerConfiguration> </wsp:All> </wsp:ExactlyOne> </wsp:Policy>

    Note you can also configure dynamic username/password handlers instead of hardcoding alice/clarinet as shown below--for sample code, see Steps #4 and #5 again of the Username Token tutorial.

    When done with the client-side configuration, you'll need to move three configuration files from your NetBeans project to your Maven client in the client/src/main/resources folder: DoubleIt.xml, DoubleItSTSService.xml, and wsit-client.xml (make sure the last file is importing the first two.)

  8. Run the client and test under error situations to make sure security is properly occurring. Run the client as shown in Step #10 of the WSDL-first tutorial and make sure you see the same output.

    If the client is not returning the expected SOAP response, the first check would be to make sure the STS and Service WSDLs are visible from a browser as discussed at the end of Steps #4 and #6 above. If that is not the problem, reviewing the steps above and the Metro error messages returned in the Tomcat error logs can help in troubleshooting. Note that the mvn clean install tomcat:redeploy command given in Step #8, when run from the DoubleIt root folder, will deploy and undeploy both the STS (sts-war) and the web service provider (war) within a single step, helpful during debugging.

    Once the client is making SOAP calls successfully, you might wish to test with Wireshark to see the SOAP requests and responses returned. (Here are the Wireshark messages I received for this tutorial's SOAP calls.) You should be able to see that the contents within the soap envelope are being encrypted if you're using message-layer encryption and that the entire soap message is illegible if transport-layer encryption is being used.

    Finally, testing the client again under various invalid circumstances (wrong callback handler username and/or password, no trust relationship between STS and service, no SOAP header sent to service) can help confirm the STS and WSP are working properly.

  1. STS behavior is defined within the WS-Trust specification.
  2. For customizing the SAML Assertion that the STS returns, follow this section of the Metro guide.
  3. Metro WS-Trust samples are available in the samples/ws-trust folder of the Metro 2.0 binary download or viewable with the online source browser. This includes an advanced sample where the STS serves both as a token issuing and token validating party.
  4. For background information, this whitepaper (pdf) by Metro's Jiandong Guo provides an entry-level introduction to WS-Trust, see also his much more thorough Enterprise Tech Tip.
  5. Kumar Jayanti has written a blog entry showing how you can access the SAML assertion within your SEI implementation.
  6. You can develop SAMLCallbackHandlers to create your own SAML tokens--see here for more details.
  7. Other STS-related Metro documentation: Handling Token and Key Requirements at Runtime, Advanced Usages of STS in Security.
  8. Apache CXF (starting with release 2.5 onwards) provides an alternative STS.
  9. JBoss' PicketLink project also provides an open-source STS, although not tested on Tomcat.
  10. Oracle provides a proprietary Oracle STS product for which a useful FAQ (pdf) is available.
  11. Metro provides several additional security mechanisms.
  12. Links to more SAML articles are available at the end of my OpenSAML tutorial.

CRL support in WSS4J 1.6.1

Colm O hEigeartaigh - Mon, 05/30/2011 - 16:12
Support for Certificate Revocation Lists (CRLs) has been a long sought feature in WSS4J, and will arrive in the imminent release of WSS4J 1.6.1. This will ensure that the certificate used to validate a signature is not revoked by the issuing Certificate Authority.

Support for CRLs is covered by the task WSS-278. The default behaviour is that certificate revocation is not enabled for backwards compatibility reasons. Two parameters must be configured to enable certificate revocation. The first is that the WSHandlerConstants property "enableRevocation" must be set to "true", if WSS4J is being used in the context of WSHandler. If the handler architecture is not being used, then a new method has been added to the Crypto interface for signature trust validation which explicitly enables certificate revocation:
  • public boolean verifyTrust(X509Certificate[] certs, boolean enableRevocation) throws WSSecurityException;
The previous verifyTrust(certs) method has been deprecated. Please bear in mind that any custom Crypto implementation must be updated with the new method, or else you will face a compilation error on upgrading to WSS4J 1.6.1.

The second is that the Crypto instance that is used must be supplied with CRL information. This can be done in a number of different ways. The default Crypto instance that ships with WSS4J (Merlin), has a new configuration property:
  • The location of an (X509) CRL file to be loaded via CertificateFactory.generateCRL(...).
Merlin also has two new accessor methods to set/get a CertStore object to be used for CRL checking (i.e. setCRLCertStore(CertStore crlCertStore)), if you wish to supply CRL information programatically to the Crypto instance.

Update: You can see a test for this feature here.
Categories: Colm O hEigeartaigh

Web Service Links (29 May 2011)

Glen Mazza - Sun, 05/29/2011 - 13:00

Web service related links of interest this week:


Apache XML Security for Java 1.4.5 released

Colm O hEigeartaigh - Fri, 05/27/2011 - 15:53
Apache XML Security for Java 1.4.5 has been released:
The Apache Santuario team are pleased to announce the release of
version 1.4.5 of the Apache XML Security for Java library. This
release fixes a thread safety issue in the ResourceResolver, and a
regression in signature generation for the Canonical XML 1.1
algorithm, as well as a number of other bug fixes.

Please see the release notes for more information:

You can download the library here:
Categories: Colm O hEigeartaigh

Weekend Talendization: Moving a Web Service from servlet to OSGi deployment

Glen Mazza - Fri, 05/27/2011 - 13:00

I recently updated my WSDL-first tutorial to show how to deploy a web service on free and open source Talend Service Factory's OSGi container. Configuration information with both OSGI Blueprint Specification and Spring-DM alternatives are provided. The TSF OSGi container is based on Apache Karaf but preconfigured for easy deployment of CXF-based web services. For those accustomed to web service deployment on servlet containers and new to OSGi, now might be a good time to experiment with OSGi deployment using information in my updated tutorial.

Consult the TalendForge ESB Forum for any questions or problems you may run into. Of course, don't forget Talend Service Factory's User's Guide and examples download for further assistance.


Creating a WSDL-first web service with Apache CXF or GlassFish Metro

Glen Mazza - Tue, 05/24/2011 - 13:00

Updated September 2011.

Just need to create a SOAP client? See this tutorial instead. A video for the below tutorial is also available.

This tutorial shows how to create a WSDL-first web service using either Apache CXF or GlassFish Metro. We'll be using Maven as our build tool, with web service deployment on either Tomcat (for CXF or Metro) or Talend Service Factory's OSGi container (CXF only). We'll also create a standalone SOAP client that calls the web service, which takes an integer from the SOAP request and returns the number doubled in value.

For servlet deployment, familiarity with web application resource (WAR) files and deploying them to your particular servlet container or Java application server will be needed, but basic instructions are given for Tomcat (6.0.x or 7.0.x) below. For OSGi, deployment using Talend Service Factory will be covered in detail below. The source files can be downloaded here.

  1. Download Talend Service Factory. (optional) This step is only if you're using CXF and wish to deploy on an OSGi container instead of Tomcat. The Talend Service Factory OSGi container is based on Apache Karaf and comes pre-configured for CXF web services. Download the latest release binary distribution and extract it into its own folder. If you're new to TSF it would be good to review the README files in the download, and you also may wish to download the User's Guide and examples, also available on the TSF download page.

  2. Create the project file structure. Following Maven's standard directory layout, create a "DoubleIt" folder and from there copy-and-paste the appropriate set of directory creation commands:

    for Linux: mkdir -p client/src/main/java/client mkdir -p service/src/assembly mkdir -p service/src/main/java/service mkdir -p service/src/main/resources mkdir -p war/src/main/webapp/WEB-INF for Windows: mkdir client\src\main\java\client mkdir service\src\assembly mkdir service\src\main\java\service mkdir service\src\main\resources mkdir war\src\main\webapp\WEB-INF
  3. Create and configure the Maven pom files. The following files will need to be added to the specified locations. If you are using Metro instead of CXF, make sure to modify the pom.xml and service/pom.xml files below by moving the <activation/&gt element from the CXF profile to the Metro one. (Because of the dependency the client pom has on the service's JAX-WS artifacts, usage of the alternative -PMetro/-PCXF mechanism creates problems when running the SOAP client.)

    DoubleIt/pom.xml: This is the parent pom file declaring common dependencies and plugins used by the submodules (service, war, and client).

    <project xmlns="" xmlns:xsi="" xsi:schemaLocation=""> <modelVersion>4.0.0</modelVersion> <groupId></groupId> <artifactId>basic-doubleit</artifactId> <version>1.0-SNAPSHOT</version> <name>DoubleIt Web Service - top-level POM</name> <packaging>pom</packaging> <modules> <module>service</module> <module>war</module> <module>client</module> </modules> <properties> <>UTF-8</> </properties> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-eclipse-plugin</artifactId> <version>2.8</version> <configuration> <downloadSources>true</downloadSources> <!--downloadJavadocs>true</downloadJavadocs--> <!--useProjectReferences>false</useProjectReferences--> </configuration> </plugin> </plugins> </build> <profiles> <profile> <id>CXF</id> <!-- To use Metro by default, move activation element to its profile below --> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <cxf.version>2.4.2</cxf.version> </properties> <dependencies> <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-frontend-jaxws</artifactId> <version>${cxf.version}</version> </dependency> <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-transports-http</artifactId> <version>${cxf.version}</version> </dependency> </dependencies> </profile> <profile> <!-- See for more Metro/Maven config info --> <id>Metro</id> <dependencies> <dependency> <groupId>org.glassfish.metro</groupId> <artifactId>webservices-rt</artifactId> <version>2.1</version> </dependency> </dependencies> </profile> </profiles> </project>

    DoubleIt/service/pom.xml: This pom file generates the JAX-WS artifacts (using either CXF's wsdl2java or Metro's wsimport) that will be used by the web service provider and the SOAP client. The Maven Assembly Plugin is used here to create an additional JAR artifact containing just the JAX-WS objects, which be later included as a dependency in the client's pom.xml file. Important: If you're using CXF with OSGi deployment change the value of the packaging element below to bundle (instead of jar).

    <project xmlns="" xmlns:xsi="" xsi:schemaLocation=""> <modelVersion>4.0.0</modelVersion> <parent> <groupId></groupId> <artifactId>basic-doubleit</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>service-bundle</artifactId> <name>Web Service Provider</name> <packaging>jar</packaging> <url></url> <build> <plugins> <!-- Below plugin provides a separate JAR for the JAX-WS artifacts (i.e., the objects created by running wsdl2java or wsimport), as this JAR will also be used by the SOAP client. More info: --> <plugin> <artifactId>maven-assembly-plugin</artifactId> <version>2.2.1</version> <configuration> <descriptors> <descriptor>src/assembly/jaxws-jar.xml</descriptor> </descriptors> <appendAssemblyId>true</appendAssemblyId> <attach>true</attach> </configuration> <executions> <execution> <id>make-assembly</id> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> </plugin> </plugins> <pluginManagement> <plugins> <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <version>2.3.5</version> <extensions>true</extensions> </plugin> </plugins> </pluginManagement> <!-- Name of the generated WAR file --> <finalName>doubleit</finalName> </build> <profiles> <profile> <id>CXF</id> <!-- To use Metro by default, move activation element to its profile below --> <activation> <activeByDefault>true</activeByDefault> </activation> <build> <plugins> <plugin> <groupId>org.apache.cxf</groupId> <artifactId>cxf-codegen-plugin</artifactId> <version>${cxf.version}</version> <executions> <execution> <configuration> <sourceRoot> ${basedir}/target/generated-sources </sourceRoot> <wsdlOptions> <wsdlOption> <wsdl> ${basedir}/src/main/resources/DoubleIt.wsdl </wsdl> </wsdlOption> </wsdlOptions> </configuration> <goals> <goal>wsdl2java</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <configuration> <instructions> <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName> <Require-Bundle>org.apache.cxf.bundle,org.springframework.beans</Require-Bundle> <Export-Package>service</Export-Package> </instructions> </configuration> </plugin> </plugins> </build> </profile> <profile> <id>Metro</id> <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>jaxws-maven-plugin</artifactId> <version>1.12</version> <executions> <execution> <goals> <goal>wsimport</goal> </goals> <configuration> <wsdlDirectory> src/main/resources </wsdlDirectory> <wsdlFiles> <wsdlFile>DoubleIt.wsdl</wsdlFile> </wsdlFiles> <sourceDestDir> ${basedir}/target/generated-sources </sourceDestDir> </configuration> </execution> </executions> </plugin> </plugins> </build> </profile> </profiles> </project>

    DoubleIt/service/src/assembly/jaxws-jar.xml: The Maven Assembly Plugin uses this file to create a JAR containing the JAX-WS generated artifacts.

    <assembly> <id>jaxws</id> <formats> <format>jar</format> </formats> <includeBaseDirectory>false</includeBaseDirectory> <fileSets> <fileSet> <directory>target/classes/org</directory> <outputDirectory>/org</outputDirectory> </fileSet> </fileSets> </assembly>

    DoubleIt/war/pom.xml: This pom creates the WAR file that will host the web service if you're using Tomcat. It is not needed for OSGi deployment, but if you omit adding this file be sure to remove this module from the module list in the parent pom.xml. (Note: if you're using Tomcat 6.x instead of Tomcat 7.x, change the Tomcat Maven Plugin's configuration URL below to http://localhost:8080/manager.) <project xmlns="" xmlns:xsi="" xsi:schemaLocation=""> <modelVersion>4.0.0</modelVersion> <parent> <groupId></groupId> <artifactId>basic-doubleit</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>service-war</artifactId> <name>Service WAR file</name> <packaging>war</packaging> <url></url> <dependencies> <dependency> <groupId></groupId> <artifactId>service-bundle</artifactId> <version>1.0-SNAPSHOT</version> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>tomcat-maven-plugin</artifactId> <version>1.1</version> <configuration> <server>myTomcat</server> <url>http://localhost:8080/manager/text</url> <path>/${}</path> </configuration> </plugin> <plugin> <artifactId>maven-war-plugin</artifactId> <version>2.1.1</version> <configuration> <webXml>src/main/webapp/WEB-INF/web.xml</webXml> <webResources> <resource> <directory>../service/src/main/resources</directory> <targetPath>WEB-INF/wsdl</targetPath> <includes> <include>*.wsdl</include> </includes> </resource> </webResources> </configuration> </plugin> </plugins> <!-- Name of the generated WAR file --> <finalName>doubleit</finalName> </build> </project>

    DoubleIt/client/pom.xml: This pom file includes as a dependency the JAX-WS artifact jar created above and uses the Maven Exec Plugin to activate the SOAP client.

    <?xml version="1.0" encoding="UTF-8"?> <project xmlns="" xmlns:xsi="" xsi:schemaLocation=""> <modelVersion>4.0.0</modelVersion> <parent> <groupId></groupId> <artifactId>basic-doubleit</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>client</artifactId> <name>SOAP Client</name> <packaging>jar</packaging> <dependencies> <dependency> <groupId></groupId> <artifactId>service-bundle</artifactId> <!-- Classifier below used with Maven Assembly Plugin to specify subset of above artifact needed. --> <classifier>jaxws</classifier> <version>1.0-SNAPSHOT</version> </dependency> </dependencies> <profiles> <profile> <id>Metro</id> <!-- Overrides webservices-osgi dependency possibly set in parent POM --> <!-- Activate only if using Metro & non-OSGi-deployed client --> <activation> <activeByDefault>false</activeByDefault> </activation> <dependencies> <dependency> <groupId>org.glassfish.metro</groupId> <artifactId>webservices-rt</artifactId> <version>${metro.version}</version> </dependency> </dependencies> </profile> </profiles> <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <version>1.2</version> <executions> <execution> <goals> <goal>exec</goal> </goals> </execution> </executions> <configuration> <executable>java</executable> <arguments> <argument>-classpath</argument> <classpath/> <!-- Uncomment below for debug output with Metro. --> <!--argument> </argument--> <!-- Uncomment below for debug output with CXF. Will need to configure client-side interceptors and supply a java.util.logging properties file: Place the logging file in the same directory as this pom file. --> <!--argument> </argument--> <argument> client.WSClient </argument> </arguments> </configuration> </plugin> </plugins> </build> </project>
  4. Create the web service WSDL and generate the JAX-WS artifacts. Place the below DoubleIt.wsdl file into the service/src/main/resources directory. OSGi deployment only: The endpoint URL in the soap:address location in the wsdl:service section will need to be changed due to the different default endpoint location for OSGi deployment. For the purposes of this tutorial just change the location attribute to http://localhost:8080/services/doubleit.

    <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions name="DoubleIt" xmlns:xsd="" xmlns:wsdl="" xmlns:soap="" xmlns:di="" xmlns:tns="" targetNamespace=""> <wsdl:types> <xsd:schema targetNamespace=""> <xsd:element name="DoubleIt"> <xsd:complexType> <xsd:sequence> <xsd:element name="numberToDouble" type="xsd:int"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="DoubleItResponse"> <xsd:complexType> <xsd:sequence> <xsd:element name="doubledNumber" type="xsd:int" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> </wsdl:types> <wsdl:message name="DoubleItRequest"> <wsdl:part element="di:DoubleIt" name="parameters" /> </wsdl:message> <wsdl:message name="DoubleItResponse"> <wsdl:part element="di:DoubleItResponse" name="parameters" /> </wsdl:message> <wsdl:portType name="DoubleItPortType"> <wsdl:operation name="DoubleIt"> <wsdl:input message="tns:DoubleItRequest" /> <wsdl:output message="tns:DoubleItResponse" /> </wsdl:operation> </wsdl:portType> <wsdl:binding name="DoubleItBinding" type="tns:DoubleItPortType"> <soap:binding style="document" transport="" /> <wsdl:operation name="DoubleIt"> <soap:operation soapAction=""/> <wsdl:input><soap:body use="literal"/></wsdl:input> <wsdl:output><soap:body use="literal"/></wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="DoubleItService"> <wsdl:port name="DoubleItPort" binding="tns:DoubleItBinding"> <soap:address location="http://localhost:8080/doubleit/services/doubleit"/> </wsdl:port> </wsdl:service> </wsdl:definitions>
  5. Create the servlet deployment descriptor (web.xml) file (Tomcat deployment only). The deployment descriptor below needs modification based on the web service stack you are using. Each stack uses a different startup listener and servlet to handle the web service requests. Follow the comments within the below web.xml file to configure your setup appropriately. Once done, place the file in the war/src/main/webapp/WEB-INF directory of the project.

    <?xml version="1.0" encoding="UTF-8"?> <web-app version="2.5" xmlns="" xmlns:xsi="" xsi:schemaLocation=""> <display-name>Sample web service provider</display-name> <listener> <!-- For Metro, use this listener-class instead: --> <listener-class> org.springframework.web.context.ContextLoaderListener </listener-class> </listener> <!-- Remove below context-param element if using Metro --> <context-param> <param-name>contextConfigLocation</param-name> <param-value> classpath:META-INF/cxf/cxf.xml classpath:META-INF/cxf/cxf-servlet.xml </param-value> </context-param> <servlet> <servlet-name>WebServicePort</servlet-name> <!-- For Metro, use this servlet-class instead: --> <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>WebServicePort</servlet-name> <url-pattern>/services/*</url-pattern> </servlet-mapping> <session-config> <session-timeout>60</session-timeout> </session-config> </web-app>

    Apache CXF only: The above value for contextConfigLocation is the minimum necessary to run CXF over a servlet. Note that for more advanced needs, you can change the value to "META-INF/cxf/cxf-all.xml, classpath:META-INF/cxf/cxf-servlet.xml" to load the entire CXF framework. Alternatively, in order to reduce memory demands and improve startup performance, any specific additional CXF libraries needed can be added individually.

    Next, to verify the pom.xml files and generate the JAX-WS and JAXB artifacts, enter mvn clean install from the root DoubleIt directory.

    If desired, this would be a good time to import the project into Eclipse. (This process was delayed until now because the Maven Eclipse plugin also compiles the project, a process which requires the WSDL and web.xml.) Steps:

    1. From the DoubleIt directory, run mvn eclipse:clean eclipse:eclipse. This command is configured within the DoubleIt/pom.xml file (<plugins/> section) to download the source code for dependencies.
    2. Next, within Eclipse import the three projects into the IDE using File Menu->Import->Existing Projects Into Workspace and selecting the DoubleIt root. You'll see the three Maven subprojects (client, service, war) that you can bring in. Note as just the submodules are being imported that the DoubleIt/pom.xml file will not be directly accessible from the IDE using this method--you'll need to manually open this file when desired from the Eclipse File menu.
    3. Also, if you haven't already for earlier Mavenized projects you will need to set the M2_REPO classpath variable. This allows Eclipse to use the source JARs in the Maven repository for syntax checking and code-tracing/debugging.
  6. Create the web service configuration file (Tomcat deployment only). Metro and CXF use different configuration files. These work in conjunction with (and take precedence over) the @WebService annotation on the web service provider. Metro's sun-jaxws.xml file is read by the context listener defined in the web.xml. CXF uses a Spring application context file. Copy the following sun-jaxws.xml or cxf-servlet.xml file to the war/src/main/webapp/WEB-INF directory.

    (Metro only) sun-jaxws.xml: <?xml version="1.0" encoding="UTF-8"?> <endpoints xmlns="" version="2.0"> <endpoint name="Endpoint_for_DoubleIt" implementation="service.DoubleItPortTypeImpl" wsdl="WEB-INF/wsdl/DoubleIt.wsdl" url-pattern="/services/doubleit"/> </endpoints> (CXF only) cxf-servlet.xml: <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="" xmlns:xsi="" xmlns:jaxws="" xmlns:soap="" xsi:schemaLocation=""> <!-- Import statement optional but often required if you're declaring other CXF beans in this file such as CXF's JMX MBeans --> <import resource="classpath:META-INF/cxf/cxf.xml"/> <jaxws:endpoint id="doubleit" implementor="service.DoubleItPortTypeImpl" wsdlLocation="WEB-INF/wsdl/DoubleIt.wsdl" address="/doubleit"> </jaxws:endpoint> </beans>
  7. Create the Web Service Provider. This class is commonly known as either the Service Implementation Bean (SIB) or the SEI (Service Endpoint Interface) implementation. The SEI is the DoubleItPortType class that was generated from the WSDL earlier. The methods in the SEI map to the operations defined in the portType section of the WSDL.

    Place this file in the service/src/main/java/service directory and then run mvn clean install to compile the SIB.

    package service; import javax.jws.WebService; import org.example.contract.doubleit.DoubleItPortType; @WebService(targetNamespace = "", portName="DoubleItPort", serviceName="DoubleItService", endpointInterface="org.example.contract.doubleit.DoubleItPortType") public class DoubleItPortTypeImpl implements DoubleItPortType { public int doubleIt(int numberToDouble) { return numberToDouble * 2; } }
  8. Build and deploy the WAR file. This step is different depending on whether you're deploying to Tomcat (either Metro or CXF) or Talend Service Factory (CXF only):

    Tomcat deployment: If you haven't worked with Tomcat before, here are some basic instructions for installing and configuring this servlet container. The Tomcat user's guide and mailing list can provide more help if needed.

    1. Download the latest release version of Tomcat and extract the zip or tar.gz file into a new directory.
    2. Have an environment variable $CATALINA_HOME point to your expanded Tomcat application directory, e.g. for Linux (in your ~/.bashrc file): export CATALINA_HOME=/usr/myapps/tomcat-7.x.x
    3. In the CATALINA_HOME/conf/tomcat-users.xml file, we'll need to create a user with appropriate manager permissions, different between Tomcat 6 and Tomcat 7. For Tomcat 6, create a user with a role of manager or give the "tomcat" user (which should already be in the file) the manager role: <tomcat-users> ...other entries... <role rolename="manager"/> <user username="tomcat" password="????" roles="tomcat,manager"/> </tomcat-users>

      For Tomcat 7, create a user with the role of manager-script or give the "tomcat" user the manager-script role as shown below. This role allows for deploying web applications using scripting tools such as the Tomcat Maven Plugin we're using in this tutorial. Although not necessary for Tomcat deployment, I'm also giving the user the manager-gui role so he can access the browser-based Tomcat Manager HTML application, helpful for a quick authentication check. Depending on your security needs, you may or may not wish to do this in production.

      <tomcat-users> ...other entries... <role rolename="manager-script"/> <role rolename="manager-gui"/> <user username="tomcat" password="????" roles="tomcat,manager-script,manager-gui"/> </tomcat-users>
    4. Start Tomcat from a console window: {prompt}% $CATALINA_HOME/bin/
    5. If you granted the user the manager-gui role, confirm that you can log into the manager webapp at http://localhost:8080/manager/html using the username and password of the manager account.

    For Maven to be able to deploy and undeploy webapps on Tomcat, you'll need to add a server entry to your $MAVEN_HOME/conf/settings.xml file. Add the username and password for the manager account as follows:

    <servers> ... <server> <id>myTomcat</id> <username>tomcatuser</username> <password>password</password> </server> </servers>

    The war submodule's pom.xml file uses the "id" element to indicate the app server it will be deploying to.

    Next, to deploy the web service onto Tomcat, navigate to the DoubleIt/war directory and enter mvn clean install tomcat:deploy. (Use tomcat:undeploy tomcat:deploy, or simply tomcat:redeploy, on subsequent runs to first remove the previous deployment.) This single command string does all of the following:

    • Deletes the service/target output folder if it already exists (same as mvn clean alone)
    • Recreates the folder and generates and compiles the Java classes into it (mvn package)
    • Creates a WAR file for the web service provider and JAR file for the JAX-WS artifacts (mvn package)
    • Installs the JAR and WAR into your local Maven repository (mvn install)
    • Undeploys the previous WAR file (if also using tomcat:undeploy or tomcat:redeploy)
    • Deploys the new WAR file onto Tomcat. (mvn tomcat:deploy)

    After deployment, make sure you can access the web service's wsdl at http://localhost:8080/doubleit/services/doubleit?wsdl before proceeding further. If the browser reports an error message instead, check the output from Tomcat's console window and/or server logs (in $CATALINA_HOME/logs) for troubleshooting clues.

    OSGi deployment on Talend Service Factory: Follow the below steps:

    1. OSGi configuration of the web service provider can be done in either two ways--your choice--using the OSGi Blueprint Specification or Spring-Dynamic Modules (DM). For Spring-DM, in the service submodule create the src/main/resources/META-INF/spring folder structure and place the following beans.xml file there:

      <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="" xmlns:xsi="" xmlns:jaxws="" xmlns:soap="" xsi:schemaLocation=""> <import resource="classpath:META-INF/cxf/cxf.xml" /> <import resource="classpath:META-INF/cxf/osgi/cxf-extension-osgi.xml" /> <jaxws:endpoint id="doubleit" implementor="service.DoubleItPortTypeImpl" wsdlLocation="DoubleIt.wsdl" address="http://localhost:8081/doubleit/services/doubleit"> </jaxws:endpoint> </beans>

      If you wish to use blueprint instead, in the service submodule, under src/main/resources/OSGI-INF/blueprint, place the following service.xml file:

      <blueprint xmlns="" xmlns:xsi="" xmlns:cm="" xmlns:jaxws="" xmlns:cxf="" xsi:schemaLocation=" "> <jaxws:endpoint id="doubleit" implementor="service.DoubleItPortTypeImpl" wsdlLocation="DoubleIt.wsdl" address="/doubleit"> </jaxws:endpoint> </blueprint>
    2. From the project root directory, run mvn clean install.
    3. Start Talend Service Factory from the command-line, from the container/bin folder run either ./tsf (Linux) or tsf.bat (Windows).
    4. From the TSF karaf prompt, enter: install After TSF reports the bundle ID, next enter start <bundleID>. Typing osgi:list afterwards from the Karaf prompt should show that the web service provider has successfully started. If any failure is indicated, check the container/data/log file for any error information.
    5. Prior to calling the client in the next step, make sure you can bring up the WSDL at http://localhost:8080/services/doubleit?wsdl.

    If you're having any difficulty deploying the web service, the TalendForge forums are a good source for help.

  9. Create the web service client. The following client tests the DoubleIt operation declared in the WSDL. Place the below file in the client/src/main/java/client directory.

    package client; import org.example.contract.doubleit.DoubleItPortType; import org.example.contract.doubleit.DoubleItService; public class WSClient { public static void main (String[] args) { DoubleItService service = new DoubleItService(); DoubleItPortType port = service.getDoubleItPort(); doubleIt(port, 10); doubleIt(port, 0); doubleIt(port, -10); } public static void doubleIt(DoubleItPortType port, int numToDouble) { int resp = port.doubleIt(numToDouble); System.out.println("The number " + numToDouble + " doubled is " + resp); } }
  10. Run the client code. Navigate to the client subdirectory of your project and enter mvn clean install exec:exec. You should see the following results:

    [INFO] The number 10 doubled is 20 [INFO] The number 0 doubled is 0 [INFO] The number -10 doubled is -20

    Note the client/pom.xml file has an option for activating client-side logging/debug output--if desired, just uncomment the necessary line as explained in those files.

Additional notes:
  1. For naming the elements in the WSDL, I followed the conventions used by Metro's AddNumbers.wsdl in its "fromwsdl" sample. In particular, given the stem of the WSDL name (DoubleIt), this is what I used:

    • name of wsdl:portType: DoubleItPortType
    • name of wsdl:binding: DoubleItBinding
    • name of wsdl:service: DoubleItService
    • name of port under wsdl:service: DoubleItPort

    JAX-WS WSDL-to-Java tools use these names when generating the JAX-WS classes, so following this convention helps keep the classes clearly named and understandable.

  2. The web service endpoint URL specified in the WSDL (in the wsdl:service section) is used only by the SOAP client, not the web service provider. The class used by the client has a default reference to the local WSDL from where the endpoint URL is read. For the provider, the web service stack overrides this URL with a value appropriate for the WAR's configuration. Metro and CXF employ slightly different methods to calculate the URL needed to access the web service. For our URL:

    http://localhost:8080/doubleit/services/doubleit?wsdl A B C D
    • A is the host and port of the servlet container.
    • B is the name of the war file.
    • C comes from the url-pattern element in the web.xml file.
    • D comes from the address attribute in the cxf-servlet.xml file (for CXF) or the ending stem of the url-pattern attribute in the sun-jaxws.xml file (for Metro).

    Note the above rules are for servlet deployment only. In Talend Service Factory's OSGi container, the address attribute from the Spring beans.xml or OSGI service.xml file determines the ending stem of the URL, the context (services for our endpoint URL) comes from the TSF container/etc/org.apache.cxf.osgi.cfg file and the port (8080) is declared in the TSF container/etc/org.ops4j.pax.web.cfg file.

    Note: If you're hosting the web service behind an HTTP server (that will internally forward the SOAP call to the web service provider hosted elsewhere), CXF's wsdl2java tool offers the publishedEndpointUrl setting to specify the web service URL that will appear in the WSDL's soap:address when clients make the WSDL-requesting "?wsdl" HTTP call. Note this does not change the actual endpoint URL where the SOAP service is hosted, but just gives a different address (to the HTTP server) for clients to use.

  3. Check this blog's article index for more web service tutorials and links.

Talend Links (22 May 2011)

Glen Mazza - Sun, 05/22/2011 - 13:00

Weekend Talendization - Using Talend ESB Standard Edition (II)

Glen Mazza - Fri, 05/20/2011 - 13:00

Continuing from last week's tutorial, let's go through the remaining Chapters 7 - 9 of the Getting Started Guide. These cover the following topics:

  • The TESB Service Locator (Chapter 7) - Used to decouple clients from services, by allowing for services to register and deregister their availability, and for clients to query for needed endpoints without having such endpoints initially hardcoded.
  • Service Activity Monitoring (Chapter 8) - Logging, advanced usage statistics and fault monitoring from both the client and service perspectives.
  • Enabling WS-Security (Chapter 9) - Usage of WS-Policy and a Secure Token Service (STS) in making web service calls.

Talend now an Apache Software Foundation Sponsor

Daniel Kulp - Thu, 05/19/2011 - 20:10
While I was on vacation last week, one of my “side projects” at Talend actually finished as Talend is now a Sponsor of the Apache Software Foundation. This has been something I’ve been trying to push through for quite a while. Talend (and a lot of companies) get a lot of value from the projects [...]
Categories: Daniel Kulp

Talend ESB Standard Edition released

Colm O hEigeartaigh - Wed, 05/18/2011 - 19:36
Last week the Talend ESB Standard Edition was released:
A core component of the unified platform for data services, Talend ESB includes messaging, Web services, mediation and adapters in an open and standards-based offering used to integrate distributed systems across functional, enterprise and/or geographic boundaries. Powered by leading Apache open source integration projects Apache CXF, Apache Camel and Apache ActiveMQ, Talend ESB is a versatile and flexible ESB that allows organizations to address any integration challenge, from simple departmental projects to complex, heterogeneous IT environments.Of particular interest to readers of this blog might be the Security Token Service (STS) framework which ships as part of Talend ESB. More on this in a future blog post.

To download Talend ESB Standard Edition go here. For more information, see the datasheet here.

In other Talend-related news, Talend is now a sponsor of the Apache Software Foundation.
Categories: Colm O hEigeartaigh


Subscribe to Talend Community Coders aggregator