Latest Activity

Detroit's 1826 Independence Day celebration

Glen Mazza - Mon, 07/04/2011 - 19:43

From the Detroit Gazette, July 11, 1826, page 2:

The manner in which the 50th anniversary of the Nation's Independence was celebrated in this city reflects the highest honor upon the patriotism of its citizens.

The dawn of the Jubilee was welcomed by the national salute of 24 guns. At about ten o'clock the citizens repaired to the Protestant Church, where proper religious exercises were perfomed and a sermon, replete with excellent and appropriate sentiments, was delivered by the Rev. Mr. Wells, from the 17th Psalm--"Praise ye the Lord, all ye nations: praise him, all ye people. For his merciful kindness is great towards us: and the truth of the Lord endureth forever. Praise ye the Lord."

After the exercises at the Church were terminated, the citizens repaired to the Council House, were a procession was formed, agreeably to the order of the day heretofore published. Many of the officers of the militia were in handsome uniforms--Capt. Cook's company of dragoons were also in their appropriate dress; and added much to the appearance of the procession. Among those who took their place in the procession, were the Hon. JOHN TRUMBULL, known throught the Union for his learning, and for his patriotic writings during our revolutionary struggle--and the Hon. JAMES WITHERELL, Maj. THOMPSON MAXWELL, and Col. STEPHEN MACK, all veteran "continentals." The appearance of the Detroit Mechanic Society, each member of which wore an appropriate badge upon his left breast, was creditable to the association.

The procession having been formed, it proceeded, accompanied with martial music, down Randolph Street to Woodbridge Street and down the latter to Woodward Avenue--it then proceeded to the Presbyterian Church, which was soon filled to overflowing. The exercises in the Church were conformable to the arrangements published last week. The Throne of Grace was first addressed by the Rev. Mr. Wells, who, though fatigued with the exertions of the morning, and in ill health, effectually directed the thoughts of his audience to that Great Source, from whence flows all our blessings and privileges as a nation. The Declaration of Independence was read by Col. H.J. Hunt, who introduced it by some brief and truly appropriate and patriotic remarks. It was not read for the purpose of exciting hatred, or keeping alive animosities, which were created by the most overbearing and despotic measures of a powerful government, against a weak yet brave people, who had endured almost every suffering in the catalogue of human misery, to obtain a comparative liberty--but it was annually referred to, as the best compendium of those wrongs which authorized and urged our fathers to hold the people of Great Britain as they held the rest of the world, "enemies in war, in peace friends."

The Oration was read by A.G. Whitney, Esq. It was from the pen of the venerable author of "M'Fingal", and was such as might be expected from a writer, who in "the times that tried men's souls," was held in as great dread by the Tories and enemies of our independence, as were Morgan's rifle-men, or the Virginia dragoons.

After the reading of the oration, the Rev. William Simmons addressed the Throne of Grace, and the exercises closed with an Anthem. Appropriate Psalms had been selected for the occasion, and they were sung, by the choir, under the direction of Mr. E. P. Hastings, with correctness and taste.

The committee of arrangements deserve praise for the elegant manner in which the church was decorated.

After leaving the church the procession was again formed, and proceeded to the Hotel of Capt. Woodworth, who had prepared a bountiful dinner, in the large new store-house of Mr. A. Berthelet. At three o'clock, those citizens who wished to partake of the dinner, together with the Mechanics' Society, the whole amounting to nearly two hundred, moved in procession to the store house and took their seats at the table--John P. Sheldon presiding, assisted by Col. H.J. Hunt, as vice-president.


What happened at Talend R&D summit

Sergey Beryozkin - Mon, 07/04/2011 - 13:12
Last week many of us had a chance to attend to a 3 day R&D event organized by Talend in Paris. And what a summit it was.

It was good to meet Dan, JB, Christian, our colleagues from Talend Bonn's office and of course the hosts, people who organized and run the event. The only regret I have I could not play our regular chess game with Hadrian - but I guess we have plenty of time in the future to do it again :-)

I've had a chance to attend to similar events before and I did like it very much, but this last event stands on its own. Talend is still a young company but one can't help being impressed by what this team has already achieved. The tooling is very impressive, be it Talend ESB, core Talend Data Integration or Master Data Management UI suites. They understand what managing data, jobs, processes is about, what good UI is about.

Talend ESB team has had cool demos showing how ESB consumers and producers backed up by Apache CXF can be wired in together, run as live jobs, exported as OSGI bundles, with consumers locating endpoints and users seeing the management statistics. It is really impressive, I thought it was. The new Camel Builder is the tool to explore too - it also supports linking to Talend Jobs with each Job possibly representing a super complex chain on its own.

Talend team works very hard and this team knows how to play hard too :-).

Good to be part of Apache and Talend teams...
Categories: Sergey Beryozkin

I’m now officially Talend employee

Jean-Baptiste Onofré - Mon, 07/04/2011 - 10:40
After 8 years worked at Fimasys, I decided to move last December. Fimasys is a great company but not purely middleware oriented (it’s a financial software provider). I was receiving offers from quite long time and I decided to make a choice between Talend and Fusesource. Both companies are great and I know a lot [...]
Categories: Jean-Baptiste Onofré

Apache Karaf 2.2.2 available

Jean-Baptiste Onofré - Mon, 07/04/2011 - 09:25
A new Apache Karaf version is available. If it’s mainly a bug fixes release, it includes some small enhancements. Especially, we added a completer for shell aliases. It means that you add a new command alias in etc/shell.init.script, the TAB key will look for aliases in addition of pure commands. Another interesting enhancement used in [...]
Categories: Jean-Baptiste Onofré

Web Services Links (3 July 2011)

Glen Mazza - Sun, 07/03/2011 - 17:58

Web service related links of interest this week:


Video: Deploying CXF web services with Talend Services Factory

Glen Mazza - Thu, 06/30/2011 - 17:16
I created a YouTube video for my WSDL-first tutorial for those who prefer a visual explanation for building web services with Apache CXF. Enjoy!

Custom token validation in Apache CXF 2.4

Colm O hEigeartaigh - Tue, 06/28/2011 - 15:37
A previous blog post has covered validators in Apache WSS4J 1.6, why they were introduced, what default implementations ship with WSS4J, etc. It ends with a paragraph on how to use a custom Validator implementation with Apache CXF 2.4. This post expands further on this topic.

1) Use-cases for custom Token Validation

Let's consider first of all the use-cases for specifying a custom Validator implementation in CXF. When a security header is being processed by WSS4J, it delegates each security token to a Processor implementation, depending on the QName of the token. In WSS4J 1.6, Processors do not do any validation of extracted credentials from a token, they merely process it, make sure it meets basic requirements, etc. Validation is delegated to a Validator interface which is associated with that Processor implementation.

However, there are many possible use-cases where a user may wish to replace or remove or extend the default validation behaviour associated with a particular security token. Some examples include:
  1. Validating a UsernameToken, where the CallbackHandler implementation does not have access to the password.
  2. Validating a BinarySecurityToken of some custom type.
  3. Validating the attributes of a received SAML Assertion
  4. Validating a Timestamp in a more tolerant manner than the default.
  5. Dispatching a received security token to a third-party security service for validation/authentication.
2) Configuring custom Validators in CXF
    The CXF SecurityConstants class (javadoc) defines some configuration items to override the default validators used to validate a received security token. The values associated with each configuration option must correspond to an implementation of the Validator interface. The configuration tags are:
    1. "ws-security.ut.validator" - Override UsernameToken validation.
    2. "ws-security.saml1.validator" - Override SAML1 token validation.
    3. "ws-security.saml2.validator" - Override SAML2 token validation.
    4. "ws-security.timestamp.validator" - Override Timestamp validation.
    5. "ws-security.signature.validator" - Override trust verification on a signature
    6. "ws-security.bst.validator" - Override BinarySecurityToken validation.
    To disable the validation of a particular token, specify the NoOpValidator as the value of the configuration tag corresponding to that token.

    3) Using Validators with WS-Trust

    To see the power and flexibility of the approach of separating processing from validation, consider the STSTokenValidator that ships with CXF 2.4. This validator implementation has the ability to dispatch a received BinarySecurityToken, UsernameToken, or SAML Assertion to an STS (Security Token Service) for validation via WS-Trust. On invocation, it delegates the credential to another validator (STSSamlAssertionValidator). This validator essentially catches an exception caused by a signature validation failure of the SAML Assertion and sets a flag. Only if signature validation is unsuccessful does the STSTokenValidator dispatch the token to the STS for validation.

    An example of how to configure the STSTokenValidator to validate a SAML1 Assertion against an STS in spring is as follows:

    <jaxws:endpoint ...>
        <entry key="ws-security.saml1.validator">
          <bean class=""/>
        <entry key="ws-security.sts.client">
          <bean class="">
            <constructor-arg ref="cxf"/>
            <property name="wsdlLocation" value="..."/>
            <property name="serviceName" value=".../>
            <property name="endpointName" value="..."/>

    The STSTokenValidator also has the ability to obtain a transformed token from the STS and store it in the credential, where it is available as part of the WSSecurityEngineResult under the TAG_TRANSFORMED_TOKEN tag.
    Categories: Colm O hEigeartaigh

    WADL First Development in CXF

    Sergey Beryozkin - Sun, 06/26/2011 - 23:20
    The auto-generation of WADL documents has been supported in CXF JAX-RS for a while. Letting users get a WADL instance and use a tool like soapUI to test a live RESTful endpoint is very useful.

    Don't get distracted by the fact WADL is not favoured by some REST advocates. Being able to test a live endpoint without spending time on writing a dedicated test code is good.

    CXF JAX-RS also offers a CodeGenerator filter which can be configured on test/development/POC servers for possible users being able to download the source code, compile it and start experimenting immediately. Java is just the only option there for now but of course more languages can be supported easily.

    That is all fine, but one limitation there is that what is possibly the most important WADL feature, underrated at the moment, is not really utilized. WADL is very resource centric and IMHO it's a perfect language for bridging would-be RESTful application modeling tools with the actual code. I'm not referring to UML-like modeling but a more high level approach with a tool linking entities representing root resources, subresources and data and using WADL as a internal link between a specific tool data representation and a wadl2java code generator. I'm not referring to a complex WADL XML editor here.

    All/most of us do Java-first development and it's kind of easy to assume that nobody will need a document-first development. But the document-first approach has its followers as it has its benefits.

    CXF is all about choice, options, diversity and letting users get their web services projects done using the strategies preferred in their teams. CXF 2.4.1 offers a server side WADL-first development support - give it a try and enjoy.
    Categories: Sergey Beryozkin

    Web Services Links (26 June 2011)

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

    Web service related links of interest this week:


    Talend joins JCP and JSR-339

    Sergey Beryozkin - Fri, 06/24/2011 - 22:46
    This week Talend has joined Java Community Process (JCP) and JSR-339 (JAX-RS 2.0) Expert Group (EG) with myself acting as the company representative in this EG.

    This is a good news for us working on Apache CXF as it's another vote of confidence from Talend in CXF continuing positioning itself as the best-of-breed web services framework for developing WS and REST compliant and robust service endpoints and consumers which just work.

    Talend has a history of supporting open source projects and communities. Joining JCP and supporting JAX-RS 2.0 specification is another step in that direction, simply because JAX-RS 2.0 will become important for Apache CXF users building RESTful services.

    Another reason is that Talend has a lot of experience in data-integration technologies. Talend tooling is powerful and impressive which will be a subject of another post. REST and data are good matches. Many interesting opportunities will arise for exposing data as RESTful endpoints, letting people search and link to the data of interest. It's natural Talend would like to get involved in JAX-RS 2.0.

    See this blog entry for more information.

    Categories: Sergey Beryozkin

    Talend joins the JCP

    Daniel Kulp - Wed, 06/22/2011 - 16:11
    One of the important differentiators between Apache CXF and some of it’s competitors has been it’s support for standards, both “on the wire” standards like SOAP and API standards like JAX-WS and JAX-RS. When Apache resigned from the JCP last year, there was a lot of concern about whether CXF would be able to continue [...]
    Categories: Daniel Kulp

    7000 commits later&#8230;&#8230;

    Daniel Kulp - Mon, 06/20/2011 - 17:43
    On July 22, 2005, I did my first commit into the Apache subversion repository. That commit was the first part of bringing Apache CXF (was called CeltixFire at the time) to Apache. This morning, according to svnsearch, I committed my 7000th change. That’s a lot of changes. Kind of silly milestone, but I’m proud of [...]
    Categories: Daniel Kulp

    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


    Subscribe to Talend Community Coders aggregator