Latest Activity

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

Web Services Links (15 May 2011)

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

Web service related links of interest this week:


Weekend Talendization - Using Talend ESB Standard Edition

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

Talend ESB Standard Edition was released earlier this week. Let's download it and give it a try:

  1. From the download page click on the Talend ESB button directly to download the Windows version or look under "Milestone, Release Candidate & Other Versions" for the Linux version. Reject the opportunity to download the User Documentation and Examples during the ESB download and do so manually in the next step, to make sure we get the specific version we need.
  2. On the download page, under "User Documentation and Examples", choose the first "talend-esb-4.0-doc" for the ".tar.gz" version (Linux), or the second link for the ZIP version (Windows).
  3. Extract the Talend ESB download and open the ReleaseNotes.pdf under the docs/. Review the guide and make sure your system fits the hardware and software requirements listed within it before proceeding.
  4. Extract the Talend ESB documentation and examples in the same parent folder that you extracted the Talend ESB download. This download will interleave within the ESB download, filling the /examples and /docs folders.
  5. Open the /docs/GettingStartedGuide.pdf and follow it through Chapter 6 (Importing examples into Eclipse), further if you have the time. The first six chapters cover a Rent-a-Car sample that provides a good run through web services and OSGi, later chapters cover more advanced features of Talend ESB.
  6. Review the source code for the Rent-a-Car example (under the /examples folder) to learn more about its architecture.

WS-Trust sample in Talend Service Factory 2.4.0

Colm O hEigeartaigh - Wed, 05/11/2011 - 18:18
In this post I will walk through the WS-Trust sample that ships with Talend Service Factory 2.4.0.

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).

2) Build and run the sample

Go to $TSF_HOME/examples/jaxws-ws-trust and start with the README.txt. Run "mvn eclipse:eclipse" to generate eclipse projects, and "mvn install" to build and install the various modules.

Both the CXF service provider and Metro STS used in this sample are deployed in Tomcat. To see how to configure Maven to install/uninstall these artifacts in Tomcat follow the instructions here. Finally, you need to make sure that the path to the keystores is correct for the Metro STS - follow the instructions in the README.txt for this.

Start Tomcat, and from the sts-war folder run "mvn install tomcat:deploy". Run the same command from the service-war folder to deploy the CXF service provider in Tomcat.

Finally to run the test, go to the client folder and run "mvn install exec:exec". You also have the option of running the client in Karaf (follow the instructions in the README.txt).

3) The sample

Three service invocations take place as part of this sample. For simplicity, I'll just concentrate on the third one, which shows how a SAML2 Assertion is used in a WS-Trust scenario.

3.1) The Service Provider

We'll start with the Service Provider, as the client will use the security policies defined in the WSDL of the Service Provider to access the STS. The Service is spring-loaded via the following configuration:

<jaxws:endpoint id="doubleitsaml2"
         <entry key="ws-security.callback-handler" value="..."/>
         <entry key="" value="..."/>
         <entry key="" value="false"/>

Three properties are required for the endpoint. The CallbackHandler implementation is required to provider the password used to access the private key in the Keystore, which is in turn configured in the "" file. The "" configuration turns off Basic Security Profile 1.1 compliance enforcement. This is required as the Metro STS generates a non BSP-compliant SAML Assertion (try removing this line, redeploying the service provider in tomcat and see what happens when the test is re-run).

The WSDL (DoubleIt.wsdl) contains the security policies for the service provider. It requires that the input and output SOAP Body elements must be signed and encrypted, and that all of the addressing headers must be signed in both directions. It also contains the following policy snippet:

        <sp:IssuedToken sp:IncludeToken="...AlwaysToRecipient">

This SecurityPolicy snippet defines that the communication with the service provider is secured via the SymmetricBinding, i.e. that it is secured via a secret key. The ProtectionToken policy describes how the secret key in turn is conveyed to the service provider in a secure way. In this example, it defines an IssuedToken policy, which is always sent to the recipient (service provider). Once the client sees this policy, it will know that it must contact a Security Token Service (STS) via the WS-Trust protocol to obtain a (issued) token that will convey the symmetric key to the service provider.

The IssuedToken policy has a RequestSecurityTokenTemplate policy, which the client will copy verbatim when contacting the STS for a security token. It describes the token type that is required (a SAML2 Assertion), the KeyType conveyed in the Assertion (Symmetric Key), and the size of the symmetric key (256 bits). It also contains an Issuer policy which describes how the STS may be contacted via a wsa EndpointReferenceType.

3.2) The Security Token Service (STS)

The STS used in this sample is the Metro STS. The port is secured with the following security policy binding:

         <sp:X509Token sp:IncludeToken=".../AlwaysToRecipient">
             <sp:WssX509V3Token10 />
         <sp:X509Token sp:IncludeToken=".../Never">
             <sp:WssX509V3Token10 />
             <sp:RequireIssuerSerialReference />

This Security Policy defines that the Asymmetric Binding is to be used in communication with the STS, 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 STS. 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.

The WSDL of the STS also contains a "STSConfiguration" policy fragment, which defines that the issued key is encrypted, and lists the service provider endpoints, including the corresponding public keys.

3.3) The client

When the client wants to invoke on the service provider, it parses the security policy described above in the WSDL, and sees that it must first obtain an IssuedToken from a STS before it can construct the service request. The client is configured in spring as follows:

<jaxws:client name="{...}DoubleItPortSAML2" createdFromAPI="true">
    <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="{...}IDoubleItSTS..Port"/>
        <property name="properties">
            <entry key="ws-security.signature.username" value="..."/>
            <entry key="ws-security.callback-handler" value="..."/>
            <entry key="" value="..."/>
            <entry key="" value="..."/>
            <entry key="ws-security.encryption.username" value="..."/>

The STSClient bean contains the configuration required to contact the STS. The client parses the WSDL of the STS, and uses the supplied configuration parameters to construct a request that is secured by the Asymmetric Binding, as discussed above. This request is done via the WS-Trust protocol.

3.4) The STS request

In the SOAP Body of the request is the following information (decrypted):

    <wst:BinarySecret Type=".../Nonce">...</wst:BinarySecret>

The SecondaryParameters element is copied verbatim from the RequestSecurityTokenTemplate defined in the policy of the service provider. The RequestType element defines an "Issue" URI. AppliesTo refers to the address of the service provider. Entropy contains some client-generated entropy (which the STS will combine with its own Entropy to form a symmetric key), using the ComputedKeyAlgorithm URI.

3.5) The STS response

The response from the STS contains the following (decrypted) SOAP Body. It contains the token type of the requested token, the token itself, different ways of referring to the requested token, some entropy that the client can use to recreate the symmetric key, the lifetime of the requested token, etc:

      <trust:BinarySecret Type=".../Nonce">...</trust:BinarySecret>

The requested security token that is returned above is reproduced here. Note that the SubjectConfirmation Method is "holder-of-key", meaning that the client must illustrate proof of possession of the key contained in the EncryptedKey element of the Assertion. The EncryptedKey element is encrypted using the service provider's public key.

<saml2:Assertion ID="..." IssueInstant="..." Version="2.0">
    <saml2:NameID NameQualifier="...">...</saml2:NameID>
    <saml2:SubjectConfirmation Method="...:cm:holder-of-key">
 <saml2:Conditions NotBefore="..." NotOnOrAfter="..."></saml2:Conditions>

3.5) The Service Provider request

Once the client receives the Issued Token from the STS, it recreates the symmetric key needed to communicate with the service provider, by combining the entropy received from the STS with its own entropy to form the session key. The (decrypted) SAML2 Assertion is inserted into the security header "as is". The symmetric key is referenced in the request via the following structure:

<ds:KeyInfo Id="...">
  <wsse:SecurityTokenReference  wsse11:TokenType="...#SAMLV2.0" >
    <wsse:KeyIdentifier ValueType="...#SAMLID">...</wsse:KeyIdentifier>

The Service Provider verifies the signature of the STS on the SAML Assertion, and then decrypts the EncryptedKey fragment using its private key, to obtain the symmetric key used to decrypt/verify the client request. As the confirmation method is "holder-of-key", the Service Provider ensures that the same key was used to sign some portion of the request, thus proving that the client is in possession of the key.
Categories: Colm O hEigeartaigh

How to use Camel transport with CXF JAX-RS endpoints

Sergey Beryozkin - Tue, 05/10/2011 - 13:07
The following configuration shows how to have HTTP or JMS messages forwarded to
CXF JAX-RS endpoints in Camel:

<jaxrs:server address="camel://direct:bookStore"

<camelContext xmlns="">

<!-- JMS to CXF JAX-RS -->
<from uri="jms://test.bookStore"/>
<to uri="direct:bookStore"/>

<!-- Jetty to CXF JAX-RS -->
<to uri="direct:bookStore"/>

Note that you need to use "camel://direct:bookStore" as the address of the jaxrs endpoint and then use "direct:bookStore" in route definitions.

The above configuration will only work with the current CXF trunk and 2.3.x branch snapshots.
The address like "camel://direct:bookStore" is confusing CXF JAX-RS a bit in 2.3.4/2.4.0 and earlier.

However a workaround is available for earlier versions. Christian wrote a couple of Talend Integration Factory demos showing the workaround in action. It is just a matter of adding a simple handler into routes which will make sure CXF JAX-RS is capable of matching requests forwarded to "camel://direct:bookStore".

That said, I'd encourage those who are interested to check Christian's demos anyway, for example, the jaxrs-http-jms demo also shows how to build a Camel route which gets the response from the jaxrs endpoint and converts it using a JAXB converter and pushes it further to the JMS queue.
Categories: Sergey Beryozkin

Talend Links (8 May 2011)

Glen Mazza - Sun, 05/08/2011 - 16:09

Weekend Talendization - Using Talend Open Studio (III)

Glen Mazza - Fri, 05/06/2011 - 13:00
Prerequisite: Steps 3-5 of the April 8th article.

From the Talend Open Studio Tutorial List, go through the third tutorial, How to take advantage of the tMap component. This is the most detailed tutorial I've come across so far, providing beginners a much better feel for the wide range of TOS' data processing and manipulation capabilities. Notes:


Karaf features files in Talend Integration Factory

Glen Mazza - Thu, 05/05/2011 - 13:00

Talend Integration Factory uses a features file to facilitate loading of its examples onto its OSGi container. Here, a "feature" defines a collection of bundles optionally with additional settings, typically forming an application. Within Karaf, the bundles that make up the feature can be conveniently installed with a single features:install command. The format and options available with features files are described in the Karaf user manual.

Within Talend Integration Factory, as described in the examples README, after building the examples we must add the features repository (basically, the listing of features defined within the features.xml file) to the TIF container so it will later know which bundles to install for a given feature. We use features:addurl for this:

karaf@tif> features:addurl mvn:com.talend.if.examples/osgi/1.0/xml/features

Then, the bundles constituting any feature within that repository can be easily installed, for example, with the jaxrs-jms-http sample:

karaf@tif> features:install tif-example-jaxrs-jms-http

As defined in the features.xml file, this feature resolves to the following bundles, and the above command would be equivalent to entering the Karaf install command for each bundle:

<feature name='tif-example-jaxrs-jms-http' version='${project.version}' resolver='(obr)'> <feature version="${tif.version}">tif-ws</feature> <feature version="${activemq.version}">activemq</feature> <feature>http</feature> <bundle>mvn:com.talend.if.examples.jaxrs-jms-http/jaxrs-jms-http-common/${project.version}</bundle> <bundle>mvn:com.talend.if.examples.jaxrs-jms-http/jaxrs-jms-http-server/${project.version}</bundle> </feature>

As you can see an individual feature can embed other features, ensuring the installation of those features' bundles. Embedded features can be defined either within the same features file or within external features files linked using the repository element.


Web Services Links (1 May 2011)

Glen Mazza - Sun, 05/01/2011 - 17:23

Web service related links of interest this week:



Subscribe to Talend Community Coders aggregator