Calling OTRS Web Services from .NET

In one of the current projects I have to connect to OTRS ticketing back-end.

OTRS is an open-source ticketing application and has a web service interface. I thought that querying the OTRS from NET should be straightforward because there were some examples for PHP that looked easy enough, but I was wrong.


The Symptoms

First of all, the WSDL descriptor for the web service has to be crafted almost by hand, as the generic interface for OTRS allows you to make your own web service interfaces, picking what operations you want to allow and how you should name them. It involved a lot of work for one of the customer IT guys 😉

The second stumble is that the SOAP interface for OTRS methods uses wrapped types, so you have to make the proxy class using SVCUTIL.EXE tool with /wrapped option against the WSDL.

The third problem was that choice types in WSDL is not supported by the WCF default serializer, and you have to "downgrade" it to the old XML serializer calling SVCUTIL.EXE with additional /serializer:XmlSerializer option, too.

Finally, I managed to make a call with the C# proxy client class against OTRS, but my joy was short-lived. The call to OTRS methods always returned null as a result.

The Cause

I fired up Fiddler to investigate the SOAP call. The call was made well and the OTRS responded in kind with a SOAP response filled with data. But, a slight mismatch was detected: the namespace of the response message element was not the same as the request message. Consequently, the NET proxy didn’t deserialize the message to the right type as the namespaces of the data type in NET and the SOAP response didn’t match.

The Solution

In the generated proxy class I looked up the method response data types. In one of them I found this attribute:

[System.ServiceModel.MessageBodyMemberAttribute(Namespace=, Order=0)]

and I changed it into

[System.ServiceModel.MessageBodyMemberAttribute(Namespace=, Order=0)]

Save, build, run and enjoy the correctly-deserialized response from OTRS.

Helpful links

Things I Have Been Reading Lately
A new drop of the official SharePoint Guidance. It now covers SharePoint 2010 and further expands on the SharePoint solution architectural decisions and implementation guidelines. 
After some time using Web Client Software Factory (WCSF) guidance from Microsoft p&p team, they are now coming with a new version of web client guidance, oriented to ASP.NET with jQuery, AJAX and even ASP.NET MVC. Excellent read, even in the present rough form.

A guide to Claims-based Identity and Access Control, with a downloadable book in PDF format. It’s invaluable in understanding the new Windows Identity Framework (former Geneva Framework) and SharePoint 2010 claims-based authentication. 
Web Service Security Guidance for WCF, available as an online book and as a PDF file. I admit that WCF is a huge step forward in distributed applications but the security implications are too important to be left unattended. After reading this guide I had clearer image of all those pesky web.config WCF tags and their effect. Priceless when you are debugging cross-domain WCF calls 🙂

Silverlight and WCF Authentication Issues

Welcome to a new post of “My Adventures in SIlverlight” series. In this post I’ll try to outline a few caveats I found while trying to communicate a Silverlight ciient application and a WCF provider service.

The Basics

As we mentioned earlier, Silverlight only recognizes basicHttpBinding protocol. It means that it cannot use web service extensions for authentication, unlike standard ASP.NET applications. Furthermore, as Silverlight is a platform-agnostic technology, it cannot use Windows authentication neither. In an enterprise environment, this is a serious handicap.

The Alternatives

Alternative #1: Non-Authenticated Service + Username + Secret Value

You can use a non-authenticated service as a endpoint for a Silverlight client to connect to. Inside the method call, insert the username and a secret value only known to both the client application and the server. This secret value should act as a second check (the first is the username) for the service.

It’s not flawless, thought, but it should be considered.

Alternative #2: Implicit Authentication

If your Silverlight application runs in the same IIS site as the service it’s trying to consume, and this requires authentication, then you can forfeit the authentication code. Silverlight can consume a secured web service without authentication as long as the service and Silverlight client application are in the same IIS site.