Pablo M. Cibraro (aka Cibrax)
My thoughts on Web Services and .NET development
-
Improve the performance of your services with Secure conversation
When SC is enabled, the token negotiation and authentication happens once compared to other tokens where that negotiation is done for each request to the service.
-
Jason Hogg is blogging
Jason Hogg is blogging, what good news. I have been working with Jason for almost two years on different projects (Shadowfax, some applications blocks, and other projects for web services).
Jason is program manager on the Patterns & Practices team, a smart guy and guru on web services.
He has been writing excellent articles about WSE, SAML and his work on Microsoft. Check out his blog at http://blogs.msdn.com/thehoggblog/ -
WS-Compression for WSE 3
Roldolfo Finochietti has written a nice implementation of WS-Compression for WSE 3.0.
You can download it here. -
Proxy factory
Last week, Sergio, a friend of mine asked me the following question about WCF "Hey Pablo, do you know how WCF does to create a channel with a specific interface on the fly ?".
-
Implementing a WS-Federation scenario with WSE
Federation is key concept that allows to enable collaboration across multiple security or trust realms.
There are many resources on Internet about this topic so I won't enter in details during this post.
The solution that I will give is based on the second extension of this pattern: -
Routing messages by means of the body element in WCF
Routing messages in this way is useful in some scenarios where the action is not available in the addressing headers or the SoapAction http header.
-
WS-Polling implementation for WSE
I used some of free time last week to write a prototype of WS-Polling for WSE 3.0.
Unfortunately, I couldn't finish the complete specification but it is enough to execute web services asynchronously.
If you haven't read anything about WS-Polling before, it is basically a specification to execute web services asynchronously and poll to the server later in order to get the response.
If you take a look to this specification, you probably will able to see three main parts:
1. A mechanism to execute web services and store the response for later retrieval
2. Some headers to query information about the status of an execution
3. A mailbox implementation
For the moment, I only implemented the first part and I'm trying to finish the second one.
Implementation structure
The diagram below illustrates the classes used by this implementation.
I defined a abstract class PollingService that declares a method to get messages. This class also uses an IMessageStore provider to store and retrieve the request and response messages for the concrete service.
The concrete service is a normal service that implements different business methods and inherits from the base class PollingService. e.g. MyHelloWorldService
The IMessageStore is an interface that declares methods to store and retrieve messages from an specific store such as Database, MSMQ or a file.
PollingClient and ConcreteProxy are both proxies to invoke methods in the Concrete service, but the last one was created by the tool WSEWsdl3.exe and it doesn't know how to invoke the service asynchronously.
I had to develop a custom PollingClient since the proxy created with WSEWsdl3.exe does not offer the following features:
1. Access to the WS-Addressing headers. For this implementation, the client must change the wsa:ReplyTo header and get access to others headers
such as wsa:MessageID and wsa:To.
2. Make a one-way call. The proxy created by the tool waits for an answer from the service in most of the cases. -
Web service security patterns released
The Patterns & Practices team has released the web service security patterns in the MSDN.
This guide provides excellent material about many security patterns and how they can be applied in different scenarios. For example, to authenticate a client or to validate a message as well. -
Interoperability between WSE 2.0 and WSE 3.0
This is probably one of the main concerns for people involved in the development of web services using WSE.
Unfortunately, WSE 3.0 was designed from the beginning to be compatible at wire level with Indigo and therefore it doesn't interoperate well with WSE 2.0.
To be clear, "Wire compatible" means equivalent messages.
I wrote this post to provide some necessary points to obtain interoperability between both versions. -
X509 Turn-Key Scenarios for WSE 3.0
If you got the chance to look into the WSE 3.0 code, maybe you noticed that it comes with two turn-key scenarios for X509 tokens, “CertificateMutualAuthenticationProfileAssertion” and “MutualCertficateAssertion” (This assertion adds some new features from WS 1.1).
Both scenarios are completely different, so I decided to write this post to describe how they work and how the keys are interchanged in each one.
First of all, I will give a brief description about a new class “EncryptedKeyToken” introduced in this version of WSE.
This introduction is really important since this token is used in many places for the assertions to encrypt messages.