Latest Activity

Web Services Links (15 May 2011)

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

Web service related links of interest this week:

Categories:

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.
Categories:

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"
      implementor="service.DoubleItPortTypeImpl"
      address="/doubleitsaml2"
      endpointName="DoubleItPortSAML2"
      wsdlLocation="WEB-INF/wsdl/DoubleIt.wsdl">
       
      <jaxws:properties>
         <entry key="ws-security.callback-handler" value="..."/>
         <entry key="ws-security.signature.properties" value="..."/>
         <entry key="ws-security.is-bsp-compliant" value="false"/>
      </jaxws:properties>
</jaxws:endpoint>

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 "ws-security.signature.properties" file. The "ws-security.is-bsp-compliant" 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:SymmetricBinding>
  <wsp:Policy>
    <sp:ProtectionToken>
      <wsp:Policy>
        <sp:IssuedToken sp:IncludeToken="...AlwaysToRecipient">
          <sp:RequestSecurityTokenTemplate>
            <t:TokenType>...#SAMLV2.0</t:TokenType>
            <t:KeyType>.../SymmetricKey</t:KeyType>
            <t:KeySize>256</t:KeySize>
          </sp:RequestSecurityTokenTemplate>
          ...
          <sp:Issuer>
            <wsaw:Address>http://.../DoubleItSTSServiceUT</wsaw:Address>
            <wsaw:Metadata>
              ...
            </wsaw:Metadata>
          </sp:Issuer>
        </sp:IssuedToken>
      </wsp:Policy>
    </sp:ProtectionToken>
    ...
  </wsp:Policy>
</sp:SymmetricBinding>

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:AsymmetricBinding>
  <wsp:Policy>
     <sp:InitiatorToken>
       <wsp:Policy>
         <sp:X509Token sp:IncludeToken=".../AlwaysToRecipient">
           <wsp:Policy>
             <sp:WssX509V3Token10 />
           </wsp:Policy>
         </sp:X509Token>
       </wsp:Policy>
       </sp:InitiatorToken>
     <sp:RecipientToken>
       <wsp:Policy>
         <sp:X509Token sp:IncludeToken=".../Never">
           <wsp:Policy>
             <sp:WssX509V3Token10 />
             <sp:RequireIssuerSerialReference />
           </wsp:Policy>
         </sp:X509Token>
       </wsp:Policy>
     </sp:RecipientToken>
      ...
  </wsp:Policy>
</sp:AsymmetricBinding>

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">
  <jaxws:properties>
    <entry key="ws-security.sts.client">
      <bean class="org.apache.cxf.ws.security.trust.STSClient">
        <constructor-arg ref="cxf"/>
        <property name="wsdlLocation" value="DoubleItSTSService.wsdl"/>
        <property name="serviceName" value="{...}DoubleItSTSService"/>
        <property name="endpointName" value="{...}IDoubleItSTS..Port"/>
        <property name="properties">
          <map>
            <entry key="ws-security.signature.username" value="..."/>
            <entry key="ws-security.callback-handler" value="..."/>
            <entry key="ws-security.signature.properties" value="..."/>
            <entry key="ws-security.encryption.properties" value="..."/>
            <entry key="ws-security.encryption.username" value="..."/>
          </map>
        </property>
      </bean>           
    </entry>
  </jaxws:properties>
</jaxws:client>

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:RequestSecurityToken>
  <wst:SecondaryParameters>
    <t:TokenType>...#SAMLV2.0</t:TokenType>
    <t:KeyType>.../SymmetricKey</t:KeyType>
    <t:KeySize>256</t:KeySize>
  </wst:SecondaryParameters>
  <wst:RequestType>.../Issue</wst:RequestType>
  <wsp:AppliesTo>
    <wsa:EndpointReference>
    ...
    </wsa:EndpointReference>
  </wsp:AppliesTo>
  ...
  <wst:Entropy>
    <wst:BinarySecret Type=".../Nonce">...</wst:BinarySecret>
  </wst:Entropy>
  <wst:ComputedKeyAlgorithm>.../CK/PSHA1</wst:ComputedKeyAlgorithm></wst:RequestSecurityToken>

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:RequestSecurityTokenResponseCollection>
  <trust:RequestSecurityTokenResponse>
    <trust:TokenType>...#SAMLV2.0</trust:TokenType>
    <trust:RequestedSecurityToken>
      <saml2:Assertion>
      ...
      </saml2:Assertion>
    </trust:RequestedSecurityToken>
    <trust:RequestedAttachedReference>...</trust:RequestedAttachedReference>
    <trust:RequestedUnattachedReference>
    ...
    </trust:RequestedUnattachedReference>
    <wsp:AppliesTo...>...</wsp:AppliesTo>
    <trust:RequestedProofToken>
        <trust:ComputedKey>.../CK/PSHA1</trust:ComputedKey>
    </trust:RequestedProofToken>
    <trust:Entropy>
      <trust:BinarySecret Type=".../Nonce">...</trust:BinarySecret>
    </trust:Entropy>
    <trust:Lifetime>
      <wsu:Created...>...</wsu:Created>
      <wsu:Expires...>...</wsu:Expires>
    </trust:Lifetime>
    <trust:KeySize>256</trust:KeySize>
  </trust:RequestSecurityTokenResponse>
</trust:RequestSecurityTokenResponseCollection>

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:Issuer>DoubleItSTSIssuer</saml2:Issuer>
  <ds:Signature>...</ds:Signature>
  <saml2:Subject>
    <saml2:NameID NameQualifier="...">...</saml2:NameID>
    <saml2:SubjectConfirmation Method="...:cm:holder-of-key">
      <saml2:SubjectConfirmationData>
      ...
      <xenc:EncryptedKey
      ...
      </xenc:EncryptedKey>
      ...
      </saml2:SubjectConfirmationData>
   </saml2:SubjectConfirmation>
 </saml2:Subject>
 <saml2:Conditions NotBefore="..." NotOnOrAfter="..."></saml2:Conditions>
 <saml2:AttributeStatement>
   <saml2:Attribute...>
     <saml2:AttributeValue>authenticated</saml2:AttributeValue>
   </saml2:Attribute>
 </saml2:AttributeStatement>
</saml2:Assertion>

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>
  </wsse:SecurityTokenReference>
</ds:KeyInfo>


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:


<beans>
<jaxrs:server address="camel://direct:bookStore"
serviceClass="service.BookStoreImpl"/>

<camelContext xmlns="http://camel.apache.org/schema/spring">

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

<!-- Jetty to CXF JAX-RS -->
<route>
<from
uri="jetty:http://0.0.0.0:9002/bookstore?matchOnUriPrefix=true"/>
<to uri="direct:bookStore"/>
</route>
</camelContext>
</beans>


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
Categories:

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:

Categories:

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.

Categories:

Web Services Links (1 May 2011)

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

Web service related links of interest this week:

Categories:

CXF JAX-RS: Moving ahead with WS-Trust integration

Sergey Beryozkin - Fri, 04/29/2011 - 18:30
Making sure existing WS-Trust STS services can be used to enforce the security of deployed web services is of high importance to customers who have invested into WS-Trust based security solutions. It's just a common sense for them.

CXF provides some very advanced support for securing communications between JAX-WS consumers and providers and delegating to STS for validating the security tokens. CXF JAX-RS endpoints rely on HTTPS. That is as far as it can get at the moment. That is sufficient in many cases but the fundamental issue is that customers who want to use STS can not depend on it for additionally securing JAX-RS endpoints.

Now, I've seen people talking about RESTifying STS services, i.e, making sure plain HTTP consumers can talk to it. That is probably a worthy idea as it is likely will make it easier to communicate with STS. It does not solve the issue of using STS for validating all sort of security tokens (SAML assertions, etc) though.

But the thing is that in CXF we have a very good integration between JAX-WS and JAX-RS frontends.
Reusing JAX-WS and WS-Security runtimes for talking to STS is the fastest and most effective way to ensure JAX-RS endpoints can also be protected with STS.

Right now, we've done a very small step forward, we can get Basic Authentication credentials validated by STS, see this section for more info.

More work will have to be done for supporting SAML assertions passed via HTTPS or as part of XML security protected payloads.

OAuth and OpenId are also there. CAS is there. Other efforts are under way. These are of interest to us. We have a brilliant OAuth contribution from Łukasz Moreń in the CXF sandbox. But at this stage the integration with WS-Trust/STS is of high priority.

Stay tuned!
Categories: Sergey Beryozkin

Talend Service Factory 2.4.0 released

Colm O hEigeartaigh - Fri, 04/29/2011 - 16:36
Talend Service Factory 2.4.0 has been released. It's based on Apache CXF 2.4.0, and so contains all of the security features in WSS4J 1.6.0, as well as the extensive support for SAML Assertions in CXF 2.4.0, that I have been blogging about for the last while.

In addition to this, some examples are available for download, which illustrate how to get these (security) features working in an OSGi container. A lot of work has gone into making sure that security libraries such as Apache Santuario, Apache WSS4J and Opensaml can be used in an OSGi environment, so I recommend checking the examples out to see how it can be done.

See Glen's blog for more information on the security examples. Also, see Sergey's blog for a discussion on some other examples based around transforming XML.
Categories: Colm O hEigeartaigh

Weekend Talendization - How to build Talend Open Studio

Glen Mazza - Fri, 04/29/2011 - 13:00

Preparing Eclipse

  1. Building Talend Open Studio in Eclipse requires additional packages to be installed on top of the standard Eclipse IDE for Java EE Developers distribution. While instructions exist for individually installing each of the needed modeling packages within the Java EE version of Eclipse, I found I only needed to explicitly install three packages because of the dependencies that these three automatically bring in.

    From Eclipse, go to Help -> Install New Software, choose "Helios - http://download.eclipse.org/releases/helios" in the Work With field, and then install the following two packages under the Modeling category:

    • ATL SDK - ATLAS Transformation Language SDK
    • Ecore Tools SDK (Incubation)

    Then add this repository to the Work With field: http://download.eclipse.org/modeling/m2t/updates/releases/ and install the most recent version of the following product:

    • M2T JET SDK 1.1.1
  2. Because Talend Open Studio is very memory intensive to build, you will probably need to set higher JVM memory allocations as discussed in the Eclipse README. Doing so prevents out-of-memory errors or otherwise very slow building performance. For my Linux 64-bit desktop with 8GB of memory I placed the following settings in an eclipse.sh file:

    ./path/to/Eclipse/folder/eclipse -vmargs -Xmx1024M -XX:MaxPermSize=256M &

    ...and then run sh eclipse.sh from a terminal window to ensure Eclipse always starts up with these options.

  3. Set the Eclipse compiler compliance level to 1.5 (Window > Preferences > Java > Compiler), as Talend Open Studio still builds with that version.

Building Talend Open Studio

  1. Download URLs for the source code are listed here. If your goal is to debug a specific version of Talend Open Studio within Eclipse, you'll want to download a tagged version. For supplying patches, usually you will want to work with the latest unreleased code in the trunk branch. To checkout trunk, use svn checkout http://talendforge.org/svn/tos/trunk. To use a tagged version, place the tag name in the URL such as svn checkout http://talendforge.org/svn/tos/tags/release-4_2_0RC1. The svn client will place the downloaded version(s) in separate folders named by default after the ending part of the checkout URL.

  2. Start Eclipse making sure to use the appropriate JVM arguments discussed in Step #2.

  3. From Eclipse, Go to File -> Import -> General -> Existing projects into workspace, and select the root folder created by the svn checkout command above ("trunk", "4_2_0RC1", etc.) Eclipse will display all the packages under that folder. Accept the entire list by selecting "Finish" from the Import dialog.

  4. Package compilation should be automatic and with error/warning results shown in the Eclipse Problems tab (Windows -> Show View -> General -> Problems). There should be zero errors (if many warnings) when finished. Any compilation bugs found can be reported (optionally with patches) to the TalendForge bugtracker.

Running Talend Open Studio from Eclipse

Instructions for running TOS from Eclipse are also in the TalendForge wiki for Linux (needs an update however) and Windows. The following steps can be used:

  1. From Eclipse, go to menu item Run -> Run Configurations or Run -> Debug Configurations (the latter if you expect to do code tracing within the IDE.)

  2. From either the Run or Debug Configurations dialog that comes up, choose Eclipse Application from the left-side tree and either right-click or select the New button to create a new configuration.

  3. Highlight the new configuration in the left-side tree and on the right-side Main tab, for Workspace Data location, choose an empty or nonexistent folder (Eclipse will create it for you if necessary). This folder is used to store any projects your IDE-run version of Talend Open Studio creates.

  4. Also on the main tab, under Program To Run, choose org.talend.rcp.branding.tos.product .

  5. Finally, select the Run (or Debug) button to activate Talend Open Studio. Note that if you've downloaded trunk instead of a specific tagged release, errors may appear as trunk contains the most recent (unreleased) checked-in code.

Consult the Talend Open Studio forums for any questions or problems that may occur for you during this process.

Categories:

Transform Feature demonstrated in Talend Service Factory 2.4.0

Sergey Beryozkin - Thu, 04/28/2011 - 14:25
Talend Service Factory 2.4.0 has several new advanced demos shipped as part of the examples distribution.

Please check Glen's blog for the information about WS-Trust and WS-SecurityPolicy demos.

Here I would like to describe a "jaxrs-jaxws-transformations" demo which shows the new Transform Feature at its best.

Many options for enhancing the existing XML schemas are possible. Usually, a namespace gets changed to indicate a breaking change to do with reordering elements, changing their names or structure or introducing new elements into a type with a closed schema content. Things are more complicated in the real world where best practices can require namespace changes for all updates made to a given schema.

The demo 'works' with the case where a Customer type has had a new optional property added to it. In addition, the namespace has also been modified, even though we are not dealing with the breaking update here.

The demo shows how:

* old and new JAX-RS clients can talk to existing (old) and new JAX-RS endpoints respectively - usual case
* old and new JAX-WS clients can talk to existing (old) and new JAX-WS endpoints respectively - usual case

Next, it shows how:

* new JAX-RS clients can talk to old JAX-RS endpoints
* new JAX-WS clients can talk to old JAX-WS endpoints

and

* old JAX-RS clients can talk to new JAX-RS endpoints
* old JAX-WS clients can talk to new JAX-WS endpoints

In this latter case, with old clients talking to new endpoints, two assumptions are made. First one is that the old clients know they are talking to new endpoints and thus Transform Feature affecting outgoing and incoming payloads is applied on the client side. Second one is that clients do not know that new endpoints will be used to handle their requests - the server side redirection and Transform Feature are used in tandem to make it work.

Finally, XMLSource is also shown in action on the client side.

This is a fairly involved demo trying to show how backward and forward compatibility may get achieved.

Try this demo and see if you can find it useful for the work you do in the real world.

Enjoy !
Categories: Sergey Beryozkin

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.

Categories:

Talend Links (24 April 2011)

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

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@github.com:Talend/tsf.git git clone -v git@github.com:Talend/tif.git

      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
Categories:

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 https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.0/systests/ws-securitycd 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:SignedSupportingTokens>
    <wsp:Policy>
        <sp:SamlToken sp:IncludeToken="...AlwaysToRecipient">
            <wsp:Policy>
                <sp:WssSamlV20Token11/>
            </wsp:Policy>
        </sp:SamlToken>
    </wsp:Policy></sp:SignedSupportingTokens>
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. ws-security.encryption.properties - 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. ws-security.signature.properties - 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,o=mock-sts.com";String subjectQualifier = "www.mock-sts.com";
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,o=mocksts.com</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);
BusFactory.setDefaultBus(busLocal);
setBus(busLocal);
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):

<jaxws:endpoint
       id="Saml2TokenOverAsymmetric"
       address="http://localhost:9001/DoubleItSaml2Asymmetric"
       serviceName="s:DoubleItService"
       endpointName="s:DoubleItSaml2AsymmetricPort"
       xmlns:s="http://WSSec/saml"
       implementor="org.apache.cxf.systest.ws.saml.server.DoubleItImpl"
       wsdlLocation="wsdl_systest_wssec/saml/DoubleItSaml.wsdl">
        
       <jaxws:properties>
           <entry key="ws-security.username" value="bob"/>
           <entry key="ws-security.callback-handler"
                  value="....KeystorePasswordCallback"/>
           <entry key="ws-security.signature.properties"
                  value="...bob.properties"/>
           <entry key="ws-security.encryption.properties"
                  value="...alice.properties"/>
           <entry key="ws-security.encryption.username" value="alice"/>
       </jaxws:properties>
 </jaxws:endpoint>

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:

_s=id=le=123

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:

Categories:

Pages

Subscribe to Talend Community Coders aggregator