Latest Activity

WS-SecurityPolicy and WS-Trust examples available in Talend Service Factory 2.4.0

Glen Mazza - Thu, 04/28/2011 - 13:00

Talend Services Factory 2.4.0, based on Apache CXF and released earlier this week, includes a new WS-Security jaxws-ws-secpol sample as well as an updated jaxws-ws-trust sample. The two Maven-based examples provide a useful addition to the WS-Security samples already available in the CXF download.

The jaxws-ws-trust sample shows a CXF web services client (WSC) authenticating to a Metro STS to obtain a SAML token which is then used to authenticate to a separate CXF web service provider (WSP). Two WSC->STS authentication scenarios are demonstrated, UsernameToken and X.509, and two types of WSCs are shown, a standalone Java application and a client running within an OSGi container. To show how different types of SAML assertions can be requested, the WSP WSDL includes policy statements for separate endpoints requiring SAML1 and SAML2 assertions. The WSC reads the SAML version requirement from the WSP WSDL and subsequently makes the appropriate SAML assertion type request to the STS. Both the WSP and STS in this sample run on standalone Tomcat.

The WS-SecurityPolicy sample provides a simpler subset of the above functionality. Here, a CXF SOAP client invokes a CXF web service provider (WSP) in two ways. The first call involves using UsernameToken secured by a SymmetricBinding policy. In the second invocation, an AsymmetricBinding policy is used to secure the message exchange, using a sender-vouches signed SAML Assertion required by the WSP.

Check the README files located in each sample's base folder for full build, deploy and run instructions.


Talend Links (24 April 2011)

Glen Mazza - Sun, 04/24/2011 - 23:32

Weekend Talendization - Building Talend's Service Factory and Integration Factory

Glen Mazza - Fri, 04/22/2011 - 13:00
The source code for Talend's Apache-licensed application integration products are publicly available on the GitHub site, specifically for Talend Service Factory (based on Apache CXF) and Talend Integration Factory (based on Apache Camel). GitHub projects naturally use Git (book, quick reference) as its source code control system. The steps below for downloading and building the latest code require JDK 6 and Maven to be already installed on your machine. Notes:
  • These instructions are not needed for those just wishing to use Talend Service Factory or Integration Factory--production releases are already available on the Talend website. Rather, these instructions are for those wishing to see, and potentially supply patches for, the latest (post-release) source code for the two projects, including still-in-development code.
  • The source code for specific product releases of Talend Service and Integration Factory can be obtained by clicking on the upper-right hand "Download" button available on the GitHub project pages for the two products. The master branch is also downloadable in this fashion as an alternative to installing a Git client as discussed below, however if you go this route it will be more difficult to create patches as well as update what you have downloaded with the latest changes.
  • The master branch frequently uses snapshot (not yet released) versions of CXF, Camel, WSS4J, and other open-source projects, switching to the production version once the dependency and the new version of the Talend software is ready for release. The SNAPSHOT versions are usually available on Apache's snapshot repository, allowing the Maven builds discussed below to run smoothly. However, in rare instances, if you see missing snapshot dependency error messages while building the Talend product, you may need to download, build and install some of the snapshot dependencies locally on your machine.
  1. Sign up for a free GitHub account.
  2. Install a Git client on your machine and set up the SSH keys as explained in these instructions: (Linux) (Windows). Notes:
    • For the Linux installation instructions, the quick and simple sudo apt-get command given at the end of the "Download and Install Git" section was all that I needed.
    • After installing on Windows, follow the "Auto-launching ssh-agent on msysgit" instructions to avoid needing to enter your SSH key passphrase with every Git command.
  3. The next step in downloading the source code depends on whether you plan on creating patches and wish to use GitHub's recommended project forking, or either don't plan on creating patches or will do so with the git diff command.
    • For project forking, follow the GitHub instructions through the "Set Up Your Local Repo" section, substituting "Spoon-Knife.git" in the git clone command with either tsf.git or tif.git.
    • For simple downloading of the master branch, from a console window, navigate to a new folder and enter one or both of the following commands, depending on the product desired: git clone -v git clone -v

      To refresh a download of the master branch with any subsequent changes made by others, navigate to the tif or tsf folder and enter git pull.

  4. To build each project, navigate to the tif and/or tsf folders and enter the usual Maven mvn clean install command. Providing no build errors, distribution of the runtime containers for Linux (*.tar.gz) and Windows (*.zip), as well as of the examples, will be subsequently available in the talend-sf (or -if)/target folder.
  5. To recommend a change to the master branch of either product, make a pull request if you're using project forking or submit a patch to the Talend JIRA by using git diff > patch.txt from the project's base directory.
  6. For those with write access to TSF/TIF (primarily Talend employees), other commands of note (check the Git references given at the top for more information on each of these commands): git status git add git remove git commit -m "Commit message" git push origin master

SAML support in CXF 2.4.0

Colm O hEigeartaigh - Thu, 04/21/2011 - 13:28
The recent Apache CXF 2.4.0 release contains support for creating, securing, processing and validating SAML Assertions according to the WS-Security 1.1 SAML Token Profile. As there is no documentation available as yet on this new feature, in this blog post I will go through a SAML system test in CXF 2.4.0 in detail.

1) Running the Test

To run the SAML system test you can do the following:

svn co ws-security
mvn compile mvn test -Dtest=SamlTokenTest
2) The Client

2.1) The Client code

You can view the source of the tests here. There are a number of tests involving creating SAML 1.1 and 2.0 assertions, and sending them to a service provider over various security bindings (Transport/Symmetric/Asymmetric). To simplify things, we will focus on the fourth test named "testSaml2OverAsymmetric". Minus some negative tests, the basic test client invocation code is as simple as:

SpringBusFactory bf = new SpringBusFactory();URL busFile = SamlTokenTest.class.getResource("client/client.xml");Bus bus = bf.createBus(busFile.toString());SpringBusFactory.setDefaultBus(bus);SpringBusFactory.setThreadDefaultBus(bus);
DoubleItService service = new DoubleItService();DoubleItPortType saml2Port = service.getDoubleItSaml2AsymmetricPort();((BindingProvider)saml2Port).getRequestContext().put("ws-security.saml-callback-handler", new SamlCallbackHandler());BigInteger result = saml2Port.doubleIt(BigInteger.valueOf(25));assert result.equals(BigInteger.valueOf(50));
2.2) The WSDL

The service is described in the WSDL here. Take a look at the WS-SecurityPolicy called "DoubleItSaml2AsymmetricPolicy", which defines the security requirements for the "DoubleItSaml2AsymmetricPort". It defines an Asymmetric Binding, where the InitiatorToken (which defines the credential used to sign the request) is always sent to the recipient, and the RecipientToken (which defines the credential used to encrypt the request) is never sent to the recipient. Both Initiator and Recipient tokens are defined as X509 tokens. The input and output policies in the WSDL enforce that the SOAP Body must be signed using the Initiator credential, and encrypted using the Recipient credential.

In addition to specifying an asymmetric binding, the policy also defines a SignedSupportingToken, which contains a SAML (2.0) Token which is always sent to the recipient. In order to successfully invoke on the service, the client must include a SAML 2.0 token in the security header of the request. This policy looks like:

        <sp:SamlToken sp:IncludeToken="...AlwaysToRecipient">
2.3) The Client configuration

The client.xml referenced in the code block above contains a jaxws:client configuration for the DoubleItSaml2AsymmetricPort. It sets the following relevant jaxws:properties:
  1. - The Crypto properties file which describes where to find the service provider's public key.
  2. ws-security.encryption.username -  The alias to use to obtain the service provider's public key from the keystore reference in the Crypto properties file above.
  3. ws-security.callback-handler - A CallbackHandler object which is expected to supply the password used to access the private key for signature creation, or decryption.
  4. - The Crypto properties file which describes where to find the client's public/private key.
  5. ws-security.signature.username - The alias to use to obtain the client's private key from the keystore reference in the Crypto properties file above.
2.3) Creating a SAML token

CXF 2.4.0 defines a new jaxws:property ("ws-security-saml-callback-handler") which specifies a CallbackHandler instance used to create SAML Assertions. This object is added to the outbound request context above dynamically, however it could also have been configured in the spring bean along with the other ws-security parameters. The CallbackHandler object used in this test can be seen here. The CallbackHandler implementation is expected to obtain a SAMLCallback object, and to set the appropriate values on this object, e.g. SAML version, Subject, issuer, Authentication/Authorization/Attribute Statements, etc. In the example provided in this test, it creates a SAML 2.0 assertion (by default), sets a mock issuer, subject and attribute statement, and sets a subject confirmation method of sender-vouches. Some code in WSS4J then constructs a SAML Assertion by processing this SAMLCallback object. It's easy to construct a SAML Assertion in this way, as the following (edited) code shows:

SAMLCallback callback = (SAMLCallback) callbacks[i];callback.setSamlVersion(SAMLVersion.VERSION_20);callback.setIssuer("sts");String subjectName = "uid=sts-client,";String subjectQualifier = "";
SubjectBean subjectBean = new SubjectBean(subjectName, subjectQualifier, SAML2Constants.CONF_SENDER_VOUCHES);callback.setSubject(subjectBean);
AttributeStatementBean attrBean = new AttributeStatementBean();attrBean.setSubject(subjectBean);AttributeBean attributeBean = new AttributeBean();attributeBean.setSimpleName("subject-role");attributeBean.setAttributeValues(Collections.singletonList("system-user"));attrBean.setSamlAttributes(Collections.singletonList(attributeBean));callback.setAttributeStatementData(Collections.singletonList(attrBean));
2.4) The service request

The service request has a security header that contains the following elements:
  1. A BinarySecurityToken which consists of the X509Certificate of the client.
  2. A Timestamp.
  3. An EncryptedKey which consists of a symmetric key encrypted with the public key of the service provider, which is used to encrypt the SOAP Body.
  4. A SAML2 Assertion.
  5. A SecurityTokenReference to the SAML Assertion.
  6. A signature which signs the Timestamp, the SAML Assertion (via the SecurityTokenReference) and the (decrypted) SOAP body. The signing credential is the BinarySecurityToken element described above.
The SAML 2.0 assertion looks like (edited):

<saml2:Assertion ... Version="2.0">    <saml2:Issuer>sts</saml2:Issuer>    <saml2:Subject>      <saml2:NameID ...>uid=sts-client,</saml2:NameID>     <saml2:SubjectConfirmation Method="...:sender-vouches">     </saml2:SubjectConfirmation>   </saml2:Subject>   <saml2:Conditions NotBefore="..." NotOnOrAfter="..."/>    <saml2:AttributeStatement>     <saml2:Attribute FriendlyName="subject-role" ...>        <saml2:AttributeValue...>system-user</saml2:AttributeValue>     </saml2:Attribute>   </saml2:AttributeStatement></saml2:Assertion>
One thing to note is that as the SAML Assertion has a subject confirmation method of "sender-vouches", the client will automatically add the quality-of-service requirement that the signature which covers the SOAP Body will also cover the SAML Assertion.

3) The Server

3.1) The Server code

The SEI implementation is here, and the Server code itself is here.  The configuration is entirely driven through the WSDL and spring configuration, and so the code is as trivial as (edited):

URL busFile = Server.class.getResource("server.xml");
Bus busLocal = new SpringBusFactory().createBus(busFile);
new Server();

3.2) The Server configuration

The server.xml configuration file referenced above can be seen here. The jaxws:Endpoint configuration for this port should be self-explanatory (edited):

           <entry key="ws-security.username" value="bob"/>
           <entry key="ws-security.callback-handler"
           <entry key=""
           <entry key=""
           <entry key="ws-security.encryption.username" value="alice"/>

The server will process the request as per the security policy in the WSDL, checking that there is a signature in the security header, that covers the SOAP Body and SAML Assertion, that the SOAP Body is Encrypted, that a Timestamp is present and valid, and that the SAML Assertion is present, and is the correct version, etc. Authentication is done on the basis of trust verification of the client's X509Certificate, which was used to verify the signature element.

The SAML Assertion is ignored beyond this point for this system test. It is saved in the security processing results, so that a custom interceptor can do some additional validation or processing on it. In a future blog post, I will describe how to validate the Assertion that has been received in some custom manner.
Categories: Colm O hEigeartaigh

CXF 2.4.0 released

Colm O hEigeartaigh - Wed, 04/20/2011 - 16:27
Apache CXF 2.4.0 has been released. CXF 2.4.0 contains a number of new and improved features in the security space. From the release statement:
WS-Security improvements including support for SAML2 tokens, improved
validation of security tokens, better performance, increased WS-I Basic
Security Profile compliance, and much more.If those new features seem familiar, it's because most of the new functionality is driven by WSS4J 1.6.0, which I've blogged extensively about over the last few months. Probably the most significant new security functionality in CXF 2.4.0 is greatly enhanced support for SAML Assertions. CXF 2.4.0 supports the ability to create, secure, process and validate SAML Assertions in accordance with the WS-Security 1.1 SAML Token Profile. I intend to blog in more detail how to use these new features in CXF 2.4.0 over the next while.

See Dan Kulp's blog for more in-depth thoughts on the new release.
Categories: Colm O hEigeartaigh

Building FIQL queries in CXF

Sergey Beryozkin - Tue, 04/19/2011 - 16:23
Building FIQL queries is not a difficult process. Typical queries are simple enough to build them manually, for example:


More complex queries relying on 'and' or 'or' conditions (possibly composed with each other) and multiple operators are a bit more tedious and complex to build.

CXF 2.4.0 introduces a SearchConditionBuilder utility class (thanks to Andy Michalec) which can be used to simplify building FIQL queries and working with CXF JAX-RS endpoints already supporting FIQL queries.

Have a look please at this section, try SearchConditionBuilder and provide the feedback.
Categories: Sergey Beryozkin

Apache CXF 2.4.0 Released!

Daniel Kulp - Mon, 04/18/2011 - 16:17
After 6 months of development, the Apache CXF team is proud to announce that 2.4.0 is now released. (official announcement) This version was a fairly large undertaking and has a bunch of significant new features. Security: WS-Security enhancements were a major theme for this release. It mostly started as work to get a new version [...]
Categories: Daniel Kulp

Web Services Links (17 April 2011)

Glen Mazza - Sun, 04/17/2011 - 13:00

Web service related links of interest this week:


WSS4J 1.6.0 released

Colm O hEigeartaigh - Fri, 04/15/2011 - 13:28
WSS4J 1.6.0 has been released:
The Apache Web Services team is pleased to announce the release of WSS4J 1.6.0. WSS4J 1.6.0 features support for SAML2 assertions, JSR-105 support, better spec compliance, performance work, support for trust-stores and a lot more besides. It is not API-compatible with the 1.5.x series of releases. For more information on the new features and changes in WSS4J 1.6.0 go to: To download WSS4J 1.6.0 go to: The Apache Web Services Team
Categories: Colm O hEigeartaigh

Weekend Talendization - Using Talend Open Studio (II)

Glen Mazza - Fri, 04/15/2011 - 13:00
Prerequisite: Steps 3-5 of last week's entry.
  1. From the TOS Tutorial List, go through the second tutorial, How to set up a Join link on a Job Design.
    • Note: The tutorial, based on a similar instructor-led tutorial, incorrectly assumes a repository containing the customer and U.S. state data is already available. (I just entered an issue tracker request to have the online text updated.) For input sources to the tFileInputDelimited_1 and _2 components, I instead used the customer.csv and state.txt files available in the tutorial download. They can be linked in, and their schema column values defined, just as described in the first tutorial.
  2. From the TOS Webinar List, view the "Data Parsing with Talend Open Studio" webinar.
  3. From the Talend white paper library, read Practical Open Source Data Integration: Case Studies & Implementation Examples (Vol. 2).

Transforming XML in CXF

Sergey Beryozkin - Thu, 04/14/2011 - 17:41
Working with XML based web services does not only involve having a proxy or HTTP client invoking on the remote endpoint with the underlying data-binding magically populating a given bean instance with the values contained in XML tags.

Working with XML also implies that some care has to be taken for all those clients distributed all over the enterprise and the WEB at large be able to consume the existing and newer endpoints.

If you have a newer endpoint deployed that can handle the payloads from the older clients then the backward compatibility is maintained. If the validation is enabled then this is usually achieved by adding optional elements to the updated schema.

What happens if you have so many endpoints that they have to be gradually replaced by newer ones, should newer clients be blocked from consuming the old endpoints ? Is it really needed if all the new payloads add is some ignorable content that makes the information about a given concept more complete for newer endpoints ? Is it even realistic as in the case of the WEB ? Is telling such clients 'wait, the endpoint is being upgraded' is the cheapest/simplest option ?

This is where the forward compatibility comes in and it implies that the unrecognized content has to be ignored. Disabling the validation is not always safe as the newer clients providing new content can expect that that new content has been processed into account as opposed to being ignored. Validation will prevent the important unrecognized tags from being dropped. But it also will prevent the forward compatibility altogether.

The new CXF Transform Feature has been introduced and hopefully it will help users with resolving all sorts of backward and forward compatibility issues. CXF JAX-WS and JAX-RS endpoints and clients can be configured for namespaces be dropped or changed, elements dropped, changed or appended to existing elements. This is all realized at the STAX XMLStreamReader and XMLStreamWriter levels so it is fast and effective.

Does your web service need to talk to the legacy server which does not understand what namespaces are ? Do you need to consume a response from the newer endpoint which has a new namespace introduced ? Do you need certain elements ignored or dropped on the input/output ?

Use the transformation feature, get inspired and write the services which just work and don't cause all the clients be recompiled/updated whenever a minor change to the new endpoint has been applied. Have the web service clients talking to a variety of endpoints without changing the code.

The use of the transform feature in combination with the servlet-based redirection allows for replacing the old endpoints with the new ones and redirecting the requests from the old clients to the new endpoints. Which is quite cool. See this web.xml (CXFServletV1 redirects to CXFServletV2, effectively changing final URI path from /v1/rest-transform to /v2/rest-transform), with CXFServletV2 serving a jaxrs:endpoint with the "restTransform" id, the last jaxrs endpoint in this beans.xml. Note this endpoint relies on the transform feature which drops the namespaces from the inbound payloads and changes the name of the outbound element, only for redirected requests - so that V1 clients can talk to V2 endpoints without V2 clients being affected.

Finally, if you use the default CXF JAX-RS JSONProvider then the transform feature can be applied to input/output JSON sequences too, surely you don't want the JSON clients failing to parse the JSON data if you happen to add one more property to the JAXB bean which is used to produce a JSON sequence :-).

Most of it can also be done by custom CXF interceptors as well, which can register custom STAX handlers or use XSLT or XPath. I've updated the Advanced XML section on the CXF JAX-RS wiki, have a look please.
Categories: Sergey Beryozkin

Jettison 1.3 is released

Sergey Beryozkin - Thu, 04/14/2011 - 17:15
As it happens, Dan and Dejan have let me manage the Jettison project from now on. And thus I'm happy to announce that Jettison 1.3 has been released.

Jettison 1.3 has had two patches from CXF users applied.

MappedXMLStreamReader can now read top-level explicit arrays containing qualified and unqualified tags - this allows JAXB to deserialize such JSON sequences into explicit collections (lists, etc). For this to work, the support for older convention assuming a top-level array may only contain a single node had to be dropped. Additionally, simple tags explicitly set to null have no CHARACTER events reported.

I think the good news is that Jettison will keep moving forward. One thing I'd like to clarify is that I won't be actively working with Jettison - however you can definitely expect patches addressing open JIRA issues being applied. Jettison has a small code base, so if you use it and see some issue then just check out the trunk and create a patch.

This latest release has really being driven by lingering issues opened against CXF JAX-RS but you don't have to use CXF for Jettison JIRAs be fixed - if you like working with Jettison then providing a patch is the only thing you need to do for the given issue be addressed :-)
Categories: Sergey Beryozkin

Deploying in cloudbees @RUN with a Jenkins Plugin

Olivier Lamy - Wed, 04/13/2011 - 18:23
Currently the way to deploy your application in cloudbees @RUN was trough the cloudbees sdk or a maven plugin.

Now you will be able to do it with a Jenkins Plugin configured in your Jenkins job.
Currently it's not yet released but a build version is available here.

Have a look at this movie. Note it's a huge movie with some suspens : so take a pop corn box and be patient :-).

Sources are available here :

The plugin uses the cloudbess client api available here :

Feel free to test it and report any issues or new features you'd like to see.

Thanks to cloudbees for the sponsorship of this developpement.

Have Fun and onward ! :-)

Categories: Olivier Lamy

Weekend Talendization - Using Talend Open Studio

Glen Mazza - Fri, 04/08/2011 - 13:00
  1. View the five-minute Talend Open Studio demo and scan its functionality.
  2. (Optional) To get a feel for the size of the Talend Open Studio community, view/skim the Talend Wiki, Components, Community Exchange, and Forums.
  3. Download the latest General Availability release of Talend Open Studio -- be sure to get the correct OS version (Linux release is located in the dropdown below the main download button).
  4. Install and run Talend Open Studio following the wiki installation instructions. Notes:
    • For tutorial purposes, the external library prerequisites (external database drivers, sort utilities) mentioned at the top of the installation guide are not needed.
    • When starting TOS, for simplicity, you can skip the registration the first time around (although useful, as it will give you a TalendForge account if you don't already have one).
    • In the Talend Open Studio startup dialog shown below, in order for the Repository, Action, and Project fields to be populated, you'll first need to enter an email account in the second field--this can be done by clicking the "..." button off to its right.

    • If you'd like visual (if somewhat slow-paced) instructions for installing on Windows, see the webinar mentioned at the bottom of this blog entry.
  5. Next do the first tutorial, "How to Sort a File", from the Open Studio tutorial list. Notes:
    • For this tutorial, it is best to start with a new blank project (two subsequent tutorials build off this one, and they can also use the same project). To do this, on the Talend Open Studio startup dialog, run the "Create a new local project" option from the Action field, enter a project name and Java generation language, and then select that new project from the Project field in the startup dialog.
    • Make sure to download the available on the tutorial page, as you'll be using one of its included CSV files.
    • To link the components in Step #5, you'll need to click directly on the component and not the shaded rectangle around it.
    • The last portion of Step #6 has the tFileCopy component overwrite the customer.csv file with the new sorted version (temp.csv) of it. I think that's ill-advisable for a tutorial as it doesn't allow you to compare before-and-after and re-run the job. Instead, you can have this component simply rename temp.csv file to something else to see this component in action without an overwrite occurring.
  6. Review Mark Madsen's report, The Role of Open Source in Data Integration (16 pages), available in the Talend white paper library.
  7. See the Talend Open Studio for Dummies webinar (30 minutes), which reviews much of the above and fills in several more areas.

Making REST calls over HTTPS (CXF and Jersey)

Glen Mazza - Fri, 04/08/2011 - 02:56

Although traditional methods involving web.xml configuration can be used to activate SSL when hosting a REST service on a standalone servlet container, both CXF JAX-RS and Jersey provide examples of hosting REST services over HTTPS with an embedded container, Jetty in the case of CXF and Grizzly with Jersey. Jersey provides the https-clientserver-grizzly sample, while CXF has its own jaxrs/basic_https sample available in the CXF download.

Provided you don't mind working with Grizzly, the Jersey sample is quite clean, modern and comprehensive. It demonstrates two-way SSL, with verification done not just by the client but also the service, and as it explains in its README, somewhat redundantly also uses Basic Authentication primarily to show how it can be done. shows the necessary client-side keystore and truststore configuration, as well as how to send the basic auth username and password. does much the same service-side, with basic auth validation being sent to a SecurityFilter class. The RootResource class further shows how the authentication username and password HTTP headers can be accessed and decoded.

I updated the CXF example earlier this week. Its Client class provides examples of making secure REST calls using the three main techniques offered by CXF--HttpClient, WebClient, and JAXRSClientFactory--with both the client and the service using certificates to authenticate each other. Some users may prefer the XML-based security configuration offered by CXF (as shown in the example, both client- and service-side). While this example does not use basic authentication, the Client class has commented sections explaining how that can be added in should the service require it. For CXF, basic authentication can be handled either at servlet container-level (web.xml), by use of interceptors or directly within the root resources by reading in the Authorization header values, for example with the following snippet, similar to the getUser() in Jersey's RootResource mentioned above: @GET public Widget getWidget(@Context HttpHeaders headers) { String auth = headers.getRequestHeader("authorization").get(0); // strip out leading "Basic " auth = auth.substring("Basic ".length()); // decode and parse username:password values String[] values = null; try { values = new String(org.apache.cxf.common.util.Base64Utility.decode(auth)).split(":"); } catch (Exception e) { // ...handle } String username = values[0]; String password = values[1]; // do username/password validation here, return exceptions if validation fails // see Jersey SecurityFilter class for a sample basic auth validation Widget widget = new Widget("wrench"); return widget; }

For information on how to implement SSL with basic auth on a standalone servlet container, see the notes for the https-server-glassfish example (which I ported to Tomcat for both Jersey and CXF) in this blog entry.

[WSS4J 1.6] Introducing Validators

Colm O hEigeartaigh - Tue, 04/05/2011 - 14:18
WSS4J 1.6 introduces the concept of a Validator, for validating credentials that have been processed by a Processor instance. This task was covered by the JIRA WSS-266.

An inbound security header is processed by WSS4J by iterating through each child element of the header, and by calling the appropriate Processor implementation to deal with each element. In WSS4J 1.5.x, some processors perform validation on the received token (e.g. UsernameTokens), whereas others store the processing results for later verification by third-party WS-Handler implementations (e.g. Timestamp verification, Certificate trust verification). There are some problems with this approach:
  • It is not consistent, some processors perform validation, others do not.
  • There is a potential security hole, in that it is assumed third-party code will know to validate the credentials that the WSS4J processors do not validate.
  • WSS4J will continue to process the rest of the security header even if the Timestamp is invalid, or the certificate non-trusted, which could lead to denial-of-service attacks.
  • There is no separation of concerns between processing the token and validating the token. If you want to change how the token is validated, you must replace the processor instance.
WSS4J 1.6 has moved Timestamp verification and certificate trust validation back into the processing of the security header, thus solving the first three points above. The fourth point is met by the new concept of Validators, as well as some changes to the way Processors and CallbackHandler implementations are used in WSS4J 1.6.

In WSS4J 1.5.x, CallbackHandler implementations are used in different ways by different processors, sometimes they are expected to verify a password (as for processing UsernameTokens), and other times they are expected to supply a password (as for decryption). In WSS4J 1.6, CallbackHandler implementations are only expected to supply a password (if it exists) to the processors. The Processor implementations do not perform any validation of the security token, instead they package up the processed token, along with any (password) information extracted from the CallbackHandler, and hand it off to a Validator implementation for Validation.

The Processor implementations get the specific Validator implementation to use via the RequestData parameter, which in turn asks a WSSConfig object for the Validator implementation. If the Validator is null, then no Validation is performed on the received token. The Processor then stores the received token as normal. WSS4J 1.6 comes with several default Validators, which are:
  • NoOpValidator: Does no processing of the credential
  • TimestampValidator: Validates a Timestamp
  • UsernameTokenValidator: Validates a UsernameToken
  • SignatureTrustValidator: Verifies trust in a signature
  • SamlAssertionValidator: Checks some HOK requirements on a SAML Assertion, and verifies trust on the (enveloped) signature.
There are some additional WSSecurityEngineResult constants that pertain to the Validator implementations:
  • TAG_VALIDATED_TOKEN: Indicates that the token corresponding to this result has been validated by a Validator implementation. Some of the processors do not have a default Validator implementation.
  • TAG_TRANSFORMED_TOKEN: A Validator implementation may transform a credential (into a SAML Assertion) as a result of Validation. This tag holds a reference to an AssertionWrapper instance, that represents a transformed version of the validated credential.
To validate an inbound UsernameToken in some custom way, simply associate the NoOpValidator with the UsernameToken QName in the WSSConfig of the RequestData object used to supply context information to the processors. After WSS4J has finished processing the security header, then extract the WSSecurityEngineResult instance corresponding to the WSConstants.UT action, and perform some custom validation on the token.

An example of how to add a custom Validator implementation is the STSTokenValidator in CXF 2.4.0. The STSTokenValidator tries to validate a received SAML Assertion locally, and if that fails, it dispatches it to a Security Token Service (STS) via the WS-Trust interface for validation. It also supports validating a UsernameToken and BinarySecurityToken in the same manner. The SecurityConstants class defines some configuration tags for specifying a custom validator for inbound SAML1, SAML2, UsernameToken, BinarySecurityToken, Signature and Timestamps. The STSTokenValidator can be configured by associating it with the appropriate configuration tag.
Categories: Colm O hEigeartaigh

Maven buildnumber plugin will support other scm : git mercurial

Olivier Lamy - Fri, 03/25/2011 - 12:00
Some of you are probably using the buildnumber-maven-plugin from codehaus to get a scm id.
The current released version 1.0-beta-4 is very svn centric.
So the current trunk has been improved to be able to support more scm : git, hg (mercurial).
The info command (yes an another svn centric name :-) ) has been implemented in Apache Maven Scm. Sure all scms are not supported but having at least svn, git and hg is a good start.

So you can test this new feature with a snapshot version : 1.0-beta-5-SNAPSHOT.

Note : to test this, you must be able to download some snapshots from various places (yes Apache Maven download the whole internet :P ).
So if you use a repo manager, you must add the following repositories :
* (for maven scm snapshots)
* (for the buildnumber plugin snapshot)
* (for maven-scm-provider-svnjava )

Update 11 April 2011 : version 1.0 released and available in central repo.

So have Fun and do not hesitate to report any issues :-)

Categories: Olivier Lamy

[WSS4J 1.6] SAML property changes

Colm O hEigeartaigh - Sun, 03/13/2011 - 16:02
A previous blog entry described how WSS4J 1.6 will have support for creating, parsing, signing, verifying, etc. SAML 2 assertions. WSS4J 1.5.x had limited support for creating and signing SAML 1.1 assertions via the default SAMLIssuer implementation, combined with a properties file. These configuration values consisted of:
  • - The SAML Issuer implementation (defaults to "").
  • - The crypto properties file corresponding to the issuer crypto instance, if the assertion is to be signed.
  • - The KeyStore alias for the issuer key.
  • - The KeyStore password for the issuer key.
  • - The issuer name
  • - Whether to send the key value or the X509Certificate. Defaults to: "false".
  • - The Subject DN.
  • - The Subject qualifier.
  • - The authentication method (e.g. "password").
  • - The confirmation method, either "senderVouches" or "keyHolder".
The configuration tags for WSS4J 1.5.x completely controlled the creation and signing of a SAML 1.1 Assertion, and hence produced only a very limited set of possible assertions.  WSS4J 1.6 takes a different approach, where the configuration tags correspond to the configuration of the issuer, i.e. whether to sign the assertion or not, the issuer name, crypto instance, etc. All instructions about how to create the SAML Assertion itself, are left to a CallbackHandler implementation.

The following configuration tags in WSS4J 1.6 are exactly the same as in WSS4J 1.5.x:
  • - The SAML Issuer implementation (defaults to "").
  • - The crypto properties file corresponding to the issuer crypto instance, if the assertion is to be signed.
  • - The KeyStore alias for the issuer key.
  • - The KeyStore password for the issuer key.
  • - The issuer name
  • - Whether to send the key value or the X509Certificate. Defaults to: "false".
The following configuration tags are new to WSS4J 1.6:
  • - Whether the SAMLIssuer implementation will sign the assertion or not. Defaults to: "false".
  • - The name of the SAML CallbackHandler implementation used to populate the SAML Assertion.

[WSS4J 1.6] Basic Security Profile 1.1 compliance

Colm O hEigeartaigh - Tue, 03/08/2011 - 14:44
The Basic Security Profile (BSP) 1.1 specification provides an industry-standard way of making sure that different WS-Security stacks can communicate with each other, by clarifying and narrowing the scope of the various WS-Security standards. WSS4J 1.5.x does not implement the BSP in any meaningful way. The WSSConfig class supports a "isWsiBSPCompliant" method (default is false), which will enable the generation of an InclusivePrefix list for signature generation, something that is mandated by the BSP spec.

WSS4J 1.6 provides support for the BSP 1.1 specification, in so far as it pertains to the core WS-Security specifications that WSS4J supports. The enforcing of BSP compliance for inbound messages is controlled by the WSSConfig class, as per WSS4J 1.5.x. An important change is that BSP compliance is now turned on by default. In addition, a new WSHandlerConstants configuration parameter has been added so that BSP compliance can be controlled via a WSHandler implementation.

Maven Surefire executing only one test method in a test class

Olivier Lamy - Thu, 02/24/2011 - 11:13
I have just worked on a improvement in Apache Maven Surefire Plugin.
Most of the time you have a test class which contains a lot of test methods.
When only one failed you have to execute all methods of the class (with -Dtest=MyClass)
This can be long and boring :-).

So now (see [1]), you will be able to use -Dtest=MyClass#myMethod to execute only the method called myMethod from the test class MyClass.

The feature has been pushed in a github fork [2].
Why in a github fork : I'd like to have feedback fast :-)

So how to test it ? :

Get the sources :

git clone git://
cd maven-surefire
mvn clean install (add -DskipTests if you don't want to execute all integration tests).

Update you pom :


And now test it :-)

-Dtest=MyTestClass#myMethod (note the support of * : -Dtest=MyTestClass#*Method )

NOTE : supported only for junit 4.x

Update : now supported for testng too.

Update 25 Feb : merged in ASF svn repo

Update 12 March : released in surefire 2.8 (Yeahhh :-) )

Have Fun ! (and don't miss to put feedback in case of issues)


Categories: Olivier Lamy


Subscribe to Talend Community Coders aggregator