This is part two of a multi-part series that describes a security interoperability project between a Secure Token Service (STS) built from Microsoft’s Windows Identify Foundation (WIF) and two open-source (java and ruby) web applications. The primary focus of the project was to secure the java/ruby web services using the STS. Part one of the series can be found here.
As noted in part I, the first quarter of the project was spent cuddled up with Google. Lots and lots of Google. Not much progress was made until said Google-Fu found an interesting tool from a Glassfish subproject hosted on java.net. The subproject was called Metro and is described as:
Metro is a high-performance, extensible, easy-to-use web service stack. It is a one-stop shop for all your web service needs, from the simplest hello world web service to reliable, secured, and transacted web service that involves .NET services
The particular Metro feature of interest was something called Web Service Interoperability Technologies (WSIT) which is a Sun inspired open-source project that provides interoperability between Java Web Services and Microsoft’s Windows Communication Foundation (WCF). The WSIT documentation suggested it was exactly what we needed to solve our interoperability challenge. In fact, “Microsoft interoperability” is explicitly mentioned in the first sentence of the introduction. It sounded like a home run.
After several missteps and some lost time tracking down issues solved by building the nightly source, we finally compiled the WSIT tools, including a handy command line program called wsimport. Theoretically, wsimport can build client classes suitable for interacting with a service that adheres to Web Service Specifications (commonly referred to by “WS-*” ). Adherence to WS-* in my case was critical because several WS-* specifications, such as WS-TRUST, are integral to the function of a standards compliant STS.
In general, once an URL to a service is acquired, wsimport will create client stubs by issuing what’s called a WS-MetadataExchange Request to obtain the Web Services Description Language (WSDL) file from the service. Next, wsimport creates classes using the requirements described in the WSDL suitable for consuming the methods exposed by the service. Definitely sounds like a home to me!
Unfortunately, reality was somewhat less exciting. The first challenge was understanding how to tease wsimport to build anything at all. The Mex I was given looked something like this:
https://mydomain.com/FederationMetadata/2007-06/FederationMetadata.xml
Despite the documentation suggesting wsimport could bootstrap from the Mex, it did nothing but complain about a missing wsdl file. [1] To this day, I’m not sure if the problem was an issue with the custom built STS, a bug in wsimport (at the time, I was using version 2.1.1; the current version is 2.2.1), or if the Mex was not a compliant MetadataExchange document.
My colleagues who built the STS were adamant there was no WSDL, only a Mex. However, we indeed found a WSDL by randomly experimenting with the links listed in the Mex document. The WSDL link looked something like this:
https://mydomain/services/issue.svc?wsdl
Home run? Not quite yet. For yet another unknown reason, wsimport refused to generate client classes with the wsdl*. More Google-Fu. More blind stumbling. Until …
I found an Apache Foundation sub-project project called CXF. The CXF project is described as:
Apache CXF is an open source services framework. CXF helps you build and develop services using front-end programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI.
What caught my eye was CXF’s support for WS-* (It appeared to adhere to nearly all WS-* standards), and the generous amount of sample code listed within the documentation. Could this be the home run?
In concept, the CXF component that builds a web service client works similarly to wsimport. In the apache case, the command line program is called wsdl2java. The documentation was clear and easy to follow and within minutes client stubs were generated using:
./apache-cxf-2.4.2/bin/wsdl2java -verbose -client -d /home/rgarabedian/cxf/src -classdir /home/rgarabedian/cxf/classes -compile https://mydomain/services/issue.svc?wsdl
This command generated many classes sprinkled throughout several packages. The key class containing the stubs used to call the methods declared in the WSDL was generated here:
com/microsoft/schemas/ws/_2008/_06/identity/securitytokenservice/
Creating these classes was cause for celebration. I distinctly remember exchanging high-fives with team members and unsuccessfully suppressing a loud whoop in the middle of the office. ( Sadly, no beer was at hand to urge the celebration further). At any rate, we had code! Real, concrete code that would compile and be used to write test programs. The ability to write programs boosted morale considerably and from this point forward the blind, helpless stumble slowly morphed into a methodical march in dim light.
Of course, we had no idea how to use the CXF generated classes and there would be more bumbling about before we arrived at the final solution. But that will be the subject of Part III of this series where I’ll dive right into the code to show how we secured our java web services with a .NET/WIF based STS.
1. Despite our lack of success with Metro and WSIT, the project appears to be actively maintained and I would still consider it a viable resource for solving interoperability problems.