Web Services
SOAP, XMLRPC, .NET and other alphabet soups.
April 2002
Sun Mon Tue Wed Thu Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        
Mar   May

















Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.

Click on the coffee mug to add Pelle Braendgaard's Instant Outline to your Radio UserLand buddy list.
 
 

11 April 2002
 

MS to drop Hailstorm

Microsoft is slowly killing of Hailstorm according to an article by John Markoff of the New York Times. He claims that MS has been slowly devesting their My Services (formerly Hailstorm) Consumer Web Services platform over the past few months, with a goal of eventually releasing "My Services" as a package for Corporates to use.

I don't know how this will affect Passport yet, but I can't imagine them halting that service for the time being, regardless of its problems. I wonder if the Citibank announcement last month will be affected by it as they were to be the prefered financial services provider for My Services.


1:52:58 PM      comment []  

IBM, MS and Verisign announce new Web Service Security Architecture

I haven't had time to read the full whitepaper yet. This Whitepaper describes their new WS-Security proposal.

This document describes a proposed strategy for addressing security within a Web service environment. It defines a comprehensive Web service security model that supports, integrates and unifies several popular security models, mechanisms, and technologies (including both symmetric and public key technologies) in a way that enables a variety of systems to securely interoperate in a platform- and language-neutral manner. It also describes a set of specifications and scenarios that show how these specifications might be used together.

I'll have a quick read and come back with any comments.


1:21:01 PM      comment []  

SOAP security and external underwear.

Jon Udell discusses the SOAPAction header and its uses for filtering SOAP requests through a firewall. The concept of the header is that the client making the SOAP Request, places a SOAPAction header in the HTTP request describing what it is they are going to be doing. For example what method they will be invoking. When I first read this a few years back it did send question marks buzzing up through my head, as you cant really on an external description of what is going to happen. Jon put's it great with his analogy of External Underwear:

Did the notion advanced in DevelopMentor's FAQ -- that SOAP packets would declare intent by publishing interface and method names in the HTTP header -- make sense? At the time it seemed reasonable to me. But now, I wonder if a SOAPaction policy isn't rather like the scene in Bananas where the newly-installed dictator declares that "everybody must wear their underwear on the outside, so we can check." The interfaces that a company chooses to expose to the world are, in the end, a policy that will or won't be enforced, regardless of the SOAP toolkits in use or the translations performed in a request pipeline. Enforcement will always require more than checking for underwear on the outside. [Jon's Radio]

Those of us who were writing perl CGI apps way back in the early days of the Web learnt that you can't rely on the format of a request. You really do need to verify all data before you make any assumptions about it, so a http SOAPAction header specifying a Stock ticker lookup interface, can just as easily have a Stock trading message within.

All of this discussion though assumes that you only have one single SOAP gateway/router on your web server. This strikes me as a bit naive from a security standpoint. I think that only interfaces with the EXACT same security properties should be exposed in the same router. This way you can use the underlying web servers security as well as external firewall's to provide access control and authentication. Lets not reinvent the wheel here.


12:13:38 AM      comment []  



© Copyright 2002 Pelle Braendgaard.
Last update: 11/04/2002; 00:13:39. <