Softwaremaker - Interoperability

All about WSDL, Types and Section 5 Encoding (again)

William Tay — Fri, 24 Oct 2008 00:58:46 GMT

Ahhh ... it has been a while, hasnt it ?

My life is just torn between working with bits of 2, beats of 4 and nucleotides of 4. But while challenging, it has been really fun. As spoken to a friend today, my passions in life seeks out to expand the comfort boundaries of gray matter, which we called the mind and to constantly challenge and stimulate the brain to learn and absorb new things that one would never think of learning if one boxed themself in a virtual space, which techies like me would call "typecast".

One example that I highlighted to my friend today, which I respectfully pointed out to them that he falls under, is when he said: "But we tech people are not good at talking to people and engaging them in meaningful conversations ..."

Typecast alert !

I ended up talking with him (not to him) for a good 20 minutes and told him we just had a meaningful conversation and that he could hold one really well. I told him that he himself set up this virtual boundary to box himself in. No one did and that he could easily remove this barrier and elevate himself to do and more importantly, to learn new things and behaviors. Instead of having new curiousities about old things, have new questions, passions and interests towards new things.

Anyways, I wont be talking about my new-found passions here but I will be briefly touching on a topic that many people knew I have passions for (and I still do) - and that is the innards and the plumbings of software technologies.

I came across types of this type of questions a lot in emails, forum questions and usergroup events:

I have this WSDL file that looks something like this:

<?xml version='1.0' encoding='UTF-8'?>

However, I need to change the add_someCustomerReturn type from xsd:string to a complex type.

I’ve made several tests variants around trying to add a complex type, like the following:

However I always end up having an error like:

Custom tool error: Unable to import WebService/Schema. Unable to import binding 'customerBinding' from namespace 'urn:customer'. Unable to import operation 'add_customer'. The datatype 'urn:customer:respType' is missing.

One thing to note is the above "web service" is using: soap:binding style="rpc". While I am not advocating one over another (document/literal), I personally think that if you stripped the religious and philisophical debates, one can certainly build a RPC-style web service using doc/literal encoding.

The above exceptions funs afoul of what many techies called: Section 5 Encoding

For the above to be resolved, you need to define a complexType reference by wsdl:part “add_someCustomerReturn” in the schema.
To do this, you MUST define wsdl:types and add the schema to the WSDL that defines the complex and change the type=”xsd:string” (of the wsdl:part) to the identifying complexType in the schema (encoded in wsdl:types)

While this is an old article written by Tim, the same principles apply. Do check it out of you need to stimulate your brain: The Argument against SOAP Encoding

OASIS and the WS-Federation Specifications

William Tay — Wed, 02 May 2007 03:39:08 GMT

Finally, OASIS announced last week that it is calling for participation for Web Services Federation. The formation of the WS-Federation Technical Committee is announced here.

WS-Fed is an important addition to the WS-* protocol suite that enables users to sign-in seamlessly to systems outside of their own organization without requiring (more) new usernames and passwords using Single-Sign-On (SSO) between separate organizations with an established trust relationship.

WS-Fed builds upon and composes with other WS-* protocols:

WS-Fed extends WS-Trust
WS-Fed composes with WS-Security and WS-SecureConversation to ensure data integrity and privacy
WS-Fed composes with WS-MetadataExchange and WS-Policy to enable simple provisioning and trust relationship configuration

Does WS-Fed compete with Liberty SAML?

Both SAML and WS-Fed enable browser-based identity federation (Passive-Mode)
However, WS-Fed enables a superset of scenarios, including:
- Seamless federation with Web Services and/or Rick-Client applications
- Separation of identities, token types, protocols and encodings
- Multi-purpose Security Token Service (STS) that can return tokens stating different assertions based upon the scenario

WS-Fed adds identity federation capabilities to the existing WS-* suite of protocols resulting in:

A single protocol stack that supports the majority of your needs and scenarios
Simplified development, deployment, management and control

The formation of the Technical Committee to drive the standardization of the WS-Fed is an important step in evolution of the industry-wide effort to create a single, comprehensive communication protocol suite that enables many current and new scenarios most effectively.

Published: WCF Interoperability with WSE 2.0 and the Migration Incentive

William Tay — Fri, 07 Jul 2006 06:11:57 GMT

Blasphemy ...

It is finally published. After many, many, and I mean, many months of paying the process tax for this piece, it is finally LIVE !

I started this piece with the first ever March 2005 CTP of Windows Communication Foundation (WCF, previously - Indigo) and I went through so many port demos and edit document cycles its so unbelievably painful ...

But it is really good to see this in online form and shape.

I started with this idea even though MSFT Corp has explicity stated that it will not support any form of interoperability between WSE 2.0 and WCF, even though it is "theoretically possible to develop Web services using WSE 2.0 in such a way that they can interoperate with WSE 3.0 (and WCF) by using only a reduced set of specifications"

More importantly, the main reason for the motivation to write such a piece is written in the article itself and I quote:

[BEGIN QUOTE]

...WSE 2.0 has seen 3 service pack releases since its official launch in 2004. It implemented the OASIS Web Services Security 1.0 specification which was the widely accepted interoperability standard protocols between secured web services as well as the implementations of WS-Addressing, WS-SecureConversation and WS-Trust. It was integrated very nicely into Visual Studio 2003. Even BizTalk Server 2004 carries with it a WSE 2.0 adapter for securing of Web Services. Thus, it would be fair to assume that there is more than its fair share of implementations in the market today.

Depending on timing, budget, complexity and a whole host of other requirements, some of these applications will need to be moved and migrated to WSE3.0 and some to WCF. Aaron Skonnard has provided a great resource in his “Service Station” column on MSDN on a brief overview on the migration of WSE 2.0 applications to WSE 3.0 ones. However, as stated in his article, there are some major changes in the programming model and architecture in WSE 3.0 and migrating them from WSE 2.0 may not be trivial.

Another very important factor to take note is while WinFX, and therefore WCF, is available downstream from Windows Vista to Windows 2003 and Windows XP. That is as far down as it goes. There still exists a huge installed base of Windows 2000 Servers out there running on server and data farms and if you need to implement the advanced Web Services stacks on those servers, WSE is still a very important strategy you cannot ignore.

As noted in the above guidelines, even though Microsoft will not guarantee interoperability between WSE 2.0 and WCF, the good news is that there are a few WSE 2.0 common scenarios, which can allow wire-interoperability with WCF. I will illustrate them in the next section...

[END QUOTE]

So, this article will outlined WHAT that reduced set of specifications are and HOW to go about using them.

Many Special Thanks go to Kirill, the Interop PM on WCF, who gave me a couple of tips to get over the port-over humps I had thoughout this piece since last year. And of course, I cannot forget Clemens, who is the catalyst to making this publication happen when he came onboard.

I hope this helps at least someone out there. Enjoy !

XAdES Interop with XML-DSIG as implemented by the .NET Framework

William Tay — Wed, 08 Feb 2006 13:18:02 GMT

What a way to start off a new category on my blog called "Interoperability".
I recently came across an interesting post in the forums that goes something like this:

[QUOTE]

Currently I'm working with Visual Studio 2003 in order to generate xmldsig signature. I'm using the class signedxml to create the xmldsig signature and I get somthing like this:

[Signature xmlns="http://www.w3.org/2000/09/xmldsig#"]
[SignedInfo]
[CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /]
............
[/Signature]

But I need the signature to be in a namespace that should be identified by
the dsig prefix:

[dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"]
[dsig:SignedInfo]
.....
[/dsig:Signature]

I really didnt think anything of this. At first glance, I thought the problem lies not in the code BUT the processor / validator that was used to read this.

The dsig or any prefix, for that matter, doesn't indicate whether they 2 use different namespaces. Check
the [default] namespaces and compare.

Strictly speaking -

[ds:Signature xmlns:ds="urn:softwaremaker.net-foo.bar" /]
[dsig:Signature xmlns:dsig="urn:softwaremaker.net-foo.bar" /]
[Signature xmlns="urn:softwaremaker.net-foo.bar /]

are isomorphically the same. If the end processor / validator reads it and treats differently, I believe that it should be a design flaw at the other end as it is really poor design to rely on namespace prefix.

If you look at the XML-Digital Signature Specifications, Section 1.3 states that:

This namespace is also used as the prefix for algorithm identifiers used by this specification. While applications MUST support XML and XML namespaces, the use of internal entities [XML] or our "dsig" XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples.

Therefore, it is NOT necessarily to have a prefix to it as long as it points to the same namespace.

However, I spoke too fast. Further explanations by the other party has made me put my thinking cap on. He provided 2 reasons being:

Compatibility with our existing signer.
We are planning to extend the signature to XML Advanced Electronic Signatures (XAdES) format. In that case the prefix is mandatory.

I am surprised [which kinda shows how much I know, or dont know ???]. I spent some minutes digging into the XML Advanced Electronic Signatures (XAdES) specifications and true enough, it declares:

The XML schema definition in clause 5 Qualifying properties syntax defines the prefix "ds" for all the XML elements already defined in [XMLDSIG], and states that the default namespace is the one defined for the present document. In consequence, in the examples of this clause, the elements already defined in [XMLDSIG] appear with the prefix "ds", whereas the new XML elements defined in the present document appear without prefix.

                              XMLDSIG 
                                   |
<ds:Signature ID?>- - - - - - - - -+- - - - -+
  <ds:SignedInfo>                  |         |
    <ds:CanonicalizationMethod/>   |         |
    <ds:SignatureMethod/>          |         |
    (<ds:Reference URI? >          |         |
      (<ds:Transforms>)?           |         |
      <ds:DigestMethod>            |         |
      <ds:DigestValue>             |         |
    </ds:Reference>)+              |         |
  </ds:SignedInfo>                 |         |
  <ds:SignatureValue>              |         |
  (<ds:KeyInfo>)?- - - - - - - - - +         |
                                             |
  <ds:Object>                                |
                                             |
    <QualifyingProperties>                   |
                                             |
      <SignedProperties>                     |
                                             |
        <SignedSignatureProperties>          |
          (SigningTime)                      |
          (SigningCertificate)               |
          (SignaturePolicyIdentifier)        |
          (SignatureProductionPlace)?        |
          (SignerRole)?                      |
        </SignedSignatureProperties>         |
                                             |
        <SignedDataObjectProperties>         |
          (DataObjectFormat)*                |
          (CommitmentTypeIndication)*        |
          (AllDataObjectsTimeStamp)*         |
          (IndividualDataObjectsTimeStamp)*  |
        </SignedDataObjectProperties>        |
                                             |
      </SignedProperties>                    |
                                             |
      <UnsignedProperties>                   |
                                             |
        <UnsignedSignatureProperties>        |
          (CounterSignature)*                |
        </UnsignedSignatureProperties>       |
                                             |
      </UnsignedProperties>                  |
                                             |
    </QualifyingProperties>                  |
                                             |
  </ds:Object>                               |
                                             |
</ds:Signature>- - - - - - - - - - - - - - - +
                                             |
                                          XAdES

Readers must take into account that the XAdES forms build up on the[XMLDSIG] by adding new XML elements containing qualifying information within the shown [XMLDSIG]ds:Object element, according to the rules defined in the present document. This ds:Object element will act as a bag for the whole set of qualifying properties defined in the present document, conveniently grouped.

So, there are 2 questions to answer here:

Is there a way to handle the Digital Signature prefix in the SignedXML Class in .NET Framework 1.1
If so - How ? If not - How ?

I decided to spend some time on this and after much disassembling some of the System.Security.Crytography.XML binaries, I found out to my dismay that the answer to Question [1] is NO. This is because the constants and the URIs of the XML Digital Signature functions in the System.Security.Crytography.XML space are found in the XMLSignature class and that class is declared as an internal class .

Therefore, the answer to Question [2] would be to build our own customized Digital Signature stack. This may actually sound harder than it is. Truth is:- With Reflector and work done behind the MONO-Project and published on Koders.com, I hacked a workaround in a few hours time. That actually means that I didnt really do much testing on it and so I disclaim myself from any liabilities, including, but not limited to, mistakes, injuries, deaths, etc caused if you choose to use it.

You would use this assembly just like you would with System.Security.Cryptography.Xml. The namespace would be Softwaremaker.NET.Security.Cryptography.Xml.PfDsigInterop.

Do take note that I has ONLY implemented the XML Digital Signature in this assembly.

Imports System
Imports System.IO
Imports System.Security.Cryptography
Imports System.Xml
Imports System.text
Imports Mono.Xml
Imports System.Text.UTF8Encoding
Imports Softwaremaker.NET.Security.Cryptography.Xml.PfDsigInterop

myRSA = New RSACryptoServiceProvider
myRSA.FromXmlString("...")

Dim doc As XmlDocument = New XmlDocument
doc.PreserveWhitespace = False
doc.Load(New XmlTextReader("..."))

Dim mySignedXML As SignedXml = New SignedXml(doc)
mySignedXML.SigningKey = myRSA

' Create a data object to hold the data to sign.
Dim dataObject As New DataObject
dataObject.Data = doc.ChildNodes
dataObject.Id = "someSWMId"

' Add the data object to the signature.
mySignedXML.AddObject(dataObject)

Dim ref As New Reference
ref.Uri = "#someSWMId"
mySignedXML.AddReference(ref)

mySignedXML.ComputeSignature()

Dim xmldg As XmlElement = mySignedXML.GetXml
' Append the element to the XML document.
doc.DocumentElement.AppendChild(doc.ImportNode(xmldg, True))

' Save the signed XML document to a file
Dim xmltw As New XmlTextWriter("...", New UTF8Encoding(False))
doc.WriteTo(xmltw)
xmltw.Close()

To verify the signed XML, we would just have to use back the System.Security.Cryptography.Xml found in the .NET Framework. At least, the .NET stack got the design of the namespaces and the prefixes right.

' Create a new XML document.
Dim xmlDocument As New XmlDocument

' Load the passedXML file into the document.
xmlDocument.Load("...")

' Create a new original SignedXml object and pass it the XML document class.
Dim signedXml As New System.Security.Cryptography.Xml.SignedXml

' Find the "Signature" node and create a new XmlNodeList object.
Dim xmlnsmgr As New XmlNamespaceManager(xmlDocument.NameTable)
xmlnsmgr.AddNamespace("SWM", "http://www.w3.org/2000/09/xmldsig#")

Dim nodeList As XmlNodeList = xmlDocument.SelectNodes("//SWM:Signature", xmlnsmgr)
signedXml.LoadXml(CType(nodeList(0), XmlElement))

myRSA = New RSACryptoServiceProvider
myRSA.FromXmlString("...")

Return signedXml.CheckSignature(myRSA)

You can download my [prefixed-XMLDSIG] custom assembly here. Do let me know if you have any comments or feedback. Enjoy !!!

[AUTHOR UPDATE]:

I have spoken to a few experts [on the standards body] about this and it seems that the concensus is that the prefix is NOT needed at all.

The XAdES specifications did not EXPLICITLY state that the prefix is needed so I don't see how the conclusions are drawn that prefixes are fixed. Maybe I am missing something.

It looked to me like all the spec was saying was that the *examples* used those prefixes.

It strikes me as surprising that any specification worth its salt would specify a *fixed prefix*. It would have been too restrictive and not something that many vendors would agree and abide.

I have advised the other party to check with the other parties/vendors for this. In the meantime, I will pull this assembly offline until I get better clarifications.

Datasets in Distributed Systems Design, Add Web Reference and All Things Evil

William Tay — Wed, 08 Feb 2006 00:42:35 GMT

Now-Now Scott, I think we both agree on my thoughts (below) since Day 1, but I wouldnt go as far as you. .

... Some issues that I have come across are the use of Datasets (a NO ! NO ! in distributed designs -- > Interop is a big problem and Datasets are TOO verbose), the inclusions of Data Schemas at the wire level when traversing network calls, etc. ...

My Evil trophy would (have) go(ne) to "Add Web Reference". Why the past tense in that ? It is rectified.