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'?>

<definitions name="someCustomer" targetNamespace="urn:someCustomer" xmlns:typens="urn:someCustomer" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/">
      <message name="add_someCustomer">
            <part name="resId" type="xsd:string"/>
            <part name="cPortable" type="xsd:string"/>
      </message>
      <message name="add_someCustomerResponse">
            <part name="add_someCustomerReturn" type="xsd:string"/>
      </message>
      <portType name="someCustomerPortType">
            <operation name="add_someCustomer">
                  <input message="typens:add_someCustomer"/>
                  <output message="typens:add_someCustomerResponse"/>
            </operation>
      </portType>
      <binding name="someCustomerBinding" type="typens:someCustomerPortType">
            <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
            <operation name="add_someCustomer">
                  <soap:operation soapAction="urn:someCustomerAction"/>
                  <input>
                        <soap:body namespace="urn:someCustomer" use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
                  </input>
                  <output>
                        <soap:body namespace="urn:someCustomer" use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
                  </output>
            </operation>
      </binding>
      <service name="someCustomerService">
            <port name="someCustomerPort" binding="typens:someCustomerBinding">
                  <soap:address location="http://foo/bar/someCustomer.php"/>
            </port>
      </service>
</definitions>

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:

      <message name="add_someCustomerResponse">
            <xsd:complexType name="respType" >
                  <xsd:sequence>
                        <xsd:element name="someStatus" type="xsd:boolean" />
                        <xsd:element name="someResult" type="xsd:boolean" />
                  </xsd:sequence>
            </xsd:complexType>
            <part name="add_someCustomerReturn" type="typens:respType"/>
      </message>

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

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.

This popped into my inbox a while ago ...

Contests like this are just great. Not only are you receiving money (if you win... Who cares, even if you dont, a digital mutation of your idea may still evolve to a sellable one), you are competing with the best to generate a innovative, marketable, secured and (hopefully) usable product. The byproduct derived from the entire process would be similar to a mini-version of an RFC. Bad and unsecured ones would have been shot down and the good ones could be made better with a few ingenious tweaks.

Now only if I can find 25.5 hours in any given day ...

During my webcast on "Why we need Reliablility in SOAP: Web Services", there were a couple of hiccups which hindered a better listening experience.

1. I cannot see the animation on the slides I am presenting, even though I am assured by the producer that the floor is seeing it. Therefore, I am "guessing" what the audience is actually seeing in my click-animation and gauging my content from there. It was neither easy nor pleasant.
2. There was a disconnect incident in my demos that also marred the listener's experience. I had to re-login again. Not Good.

Isnt it ironic? My network connection showed lack of reliability when I am talking about Reliability as a topic. . Now the least I can do is to answer a couple of questions that popped up after the session:

Q: Is RM available for all the bindings in Windows Communication Foundation (WCF, previously - Indigo) ? 
A: Yes, it is available for MOST of the standard bindings in WCF. In some bindings such as the netTcpBinding I showed, it is On-by-Default. In bindings such as wsDualHttpBinding where you need correlation of different channels and such, it is Always-On. It doesnt make sense to stick <reliableSession /> in a netMsmqBinding, for example.

Q: Is this the same WS-RM spec that is authored by IBM, Microsoft and TIBCO ? 
A: Yes. In my slide, I mentioned - I.B.M and TIBCO. I.B.M is actually the acronym I used for IBM, BEA and Microsoft.

Q: Can I get the demo you showed? 
A: No, I am sorry. In any case, my demos will not work with the lastest WinFX B2 bits today. I will need time to port them over. I recommend you go bug Shy when you see him and ask him for his WS-RM demo which consists of a WPF stack in there and a "awesomely" cool Rubik's Cube demo and is 100x better than mine.

All in all, it is quite a different experience than doing an on-stage presentation, especially when you spent an hour talking to yourself and you cannot see the audience faces and cannot manipulate your content and presentation based on their moods.

But then again, no one can see that I am wearing my Mickey-Mouse boxers while I am presenting, so I guess that is a good trade-off.

Here I am - proud to announce that I will be doing a MSDN Redmond-hosted Webcast right from the other side of the hemisphere in Singapore.

I will be speaking on concepts of Reliability in Soap:Web Services, why its needed, as well as the context of it in Windows Communication Foundation (WCF, previously - Indigo).

More importantly, a 40GB Creative (another homegrown Singaporean product) ZEN MP3 player is at stake here waiting to be won. So, do sign up quickly for a chance to win this. Rules here.

If you are one of those insomniacs in Asia-Pacific, do try to tune-in. I hope this blazes a trail for the other community leaders in Asia-Pacific to follow suit and show that we are right on par there with the best in technology.

Click here for more details on this webcast.

Apache Axis2/C version 0.91 has been released via here:
http://ws.apache.org/axis2/c/download.cgi

Key Features

1. AXIOM, an XML object model optimized for SOAP 1.1/1.2 messages with complete XML Infoset support
2. Support for One-Way Messaging (In-Only) and Request Response Messaging (In-Out)
3. Module architecture, mechanism to extend the SOAP processing model
4. Context hierarchy
5. Directory based deployment model
6. Raw XML providers
7. WS-Addressing, both the submission (2004/08) and final (2005/08) versions
8. Transports: HTTP * Both simple axis server and Apache2 httpd module and * SSL client transport - New
9. Service Groups - New
10. Service client and operation client APIs - New
11. REST support (POST case) - New
12. Module version support - New
13. MTOM support - New

Other notes

1. Interoperability tested with Axis2/Java for XML in/out client and services
2. Addressing 1.0 interoperability

Major changes since last release

1. Full Addressing 1.0 support
2. Improved fault handling model
3. SSL client transport
4. MTOM implementation
5. Implementation of easy to use service client and operation client APIs for client side programming
6. REST support (POST case)
7. Module version support
8. Service groups
9. Numerous bug fixes since last release

Un-Implemented Architecture Features (TBD in 1.0)

1. Sessions scoping for application, SOAP, transport and request levels
2. Different character encoding support
3. Dynamic invocation
4. Archive based deployment Model

Un-Implemented Architecture Features (TBD post 1.0)

1. WSDL code generation tool for stub and skeletons (based on Java tool)
2. Security module
3. REST (REpresentational State Transfer) support (GET case)
4. Web Services policy support
5. Axis2 Web application (Web App)

With regards to my post here, I thought I expand on one of many enhancements that WS-Security Specifications 1.1 brings.

"MutualCertificate11Security" assertion is one of the few security turnkey assertions in Web Services Enhancements (WSE) 3.0 and what basically it is is that the client and server are authenticated using X.509 certificates (X509SecurityToken). Message-level security is implemented using X509SecurityToken security tokens. This turnkey security assertion requires WS-Security 1.1

Once that is configured and implemented properly, it is rather interesting to see what transcends on the wire. Here is a brief snippet:

[xenc:EncryptedKey Id="SecurityToken-6ec8..." xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"]
[xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"]
[ds:DigestMethod xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /]
[/xenc:EncryptionMethod]
[KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"]
[wsse:SecurityTokenReference]
[wsse:KeyIdentifier ValueType="...oasis-wss-soap-message-security-1.1#ThumbprintSHA1" EncodingType="...oasis-200401-wss-soap-message-security-1.0#Base64Binary"]qRTA40Xfk6w1Os3mgpgy8UgwR/Y=[/wsse:KeyIdentifier]
[/wsse:SecurityTokenReference]
[/KeyInfo]
[xenc:CipherData]
[xenc:CipherValue]hBfCfVmg...[/xenc:CipherValue]
[/xenc:CipherData]
[xenc:ReferenceList]
...
[/xenc:ReferenceList]
[/xenc:EncryptedKey]

[Signature Id="Sig-b679..." xmlns="http://www.w3.org/2000/09/xmldsig#"]
  [SignedInfo]
  [ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" /]
  [SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" /]
  [Reference URI="#Id-5cdc..."]
  ...
  [/Reference]
  [/SignedInfo]
  [SignatureValue]O/PdsVMS4PTIBtrx8eyFNzbTnjc=[/SignatureValue]
  [KeyInfo]
  [wsse:SecurityTokenReference]
  [wsse:Reference URI="#SecurityToken-6ec8..." ValueType="...oasis-wss-soap-message-security-1.1#EncryptedKey" /]
  [/wsse:SecurityTokenReference]
  [/KeyInfo]
[/Signature]

[Signature xmlns="http://www.w3.org/2000/09/xmldsig#"]
  [SignedInfo]
  [ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" /]
  [SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /]
  [Reference URI="#Sig-b679..."]
  ...
  [/Reference]
  [/SignedInfo]
  [SignatureValue]PDm4wS+3hzmXugHL1wcTWZXHcaGKkODVHU48XvVNC6catxiOr25
xq9AGN8u8CgYo1JlnoEf2tuCUl86krKiUBSnMR/towfAs2doGg6a+vtjIl9F54c/VZtTPgwn
QdZtJ28E8+ep5MIS2i+9Tamnui6qpX16IS3J1FcMjVBHQpMs=
[/SignatureValue]
  [KeyInfo]
  [wsse:SecurityTokenReference]
  [wsse:Reference URI="#SecurityToken-76ae..." ValueType="...wss-x509-token-profile-1.0#X509v3" /]
  [/wsse:SecurityTokenReference]
  [/KeyInfo]
[/Signature]
...

One thing that you will noticed is that there are 2 Digital Signatures generated.

The first one has a ReferenceID, which hints that it will be subject to encryption/signatures later on, and it is signed by a EncryptedKey type (which I talked about in my earlier post). Because it is encrypted by a symmetric key "#SecurityToken-6ec8", the [SignatureValue] is rather short and this signature basically signs the soap:Body with an URI of "#Id-5cdc..." The [EncryptedKey] value can be decrypted and derived by the server's private key

The second signature basically signs the first signature (#Sig-b679...) and it signs it with the Client's Private Key that only the corresponding Public Key Pair can decrypt. The Public Key, together with the client's cert is sent over the wire via a [wsse:BinarySecurityToken] (#SecurityToken-76ae...). Because an asymmetric key is utilized here, the [SignatureValue] is relatively longer than the first signature.

As we can see from here, the first signature signs the soap:Body and the second signature signs the first signature. These are generally known as "Supporting Tokens". These additional tokens may be specified to augment the claims provided by the token associated with the “message signature” provided by the Security Binding. Supporting tokens may be specified at a different scope than the binding assertion which provides support for securing the exchange.

There are four properties related to supporting token requirements which may be referenced by a Security Binding: [Supporting Tokens], [Signed Supporting Tokens], [Endorsing Supporting Tokens] and [Signed Endorsing Supporting Tokens]. Four assertions are then defined to populate those properties: SupportingTokens, SignedSupportingTokens, EndorsingSupportingTokens, and SignedEndorsingSupportingTokens.

What I have shown above is known as the [EndorsingSupportingTokens].

The [SignedEndorsingSupportingTokens] is a combination of [SignedSupportingToken] and [EndorsingSupportingToken] and I will talk about that in a future post.

I have been back fiddling at the Web Services Enhancements (WSE) 3.0 technology space for the past few weeks and I am now grokking into the plumbings since there are quite a few forums, blogs, posts out there focusing on the higher-level abstract programming model.

I am very pleased that WSE 3.0 has implemented WS-Security Specifications 1.1 at its very core, so much so that it is the de-facto security standard to be used in most of the Turnkey Security Assertions that comes with the product.

One of the things that I have always been asking for through my contacts and channels in the OASIS WS-Security Technical Committee is the ability to sign my document snippets with a symmetric key instead. Since XML-Encryption already utilized symmetric key encryption via the [xenc:EncryptedKey] [1] for performance and throughput reasons, there is no reason why XML-Digital Signature cannot do the same. While the improvements in throughput may be slight due to the fact that in digital signatures, messages are already hashed before encryption, it is still a viable option that should be made available.

In WS-Security 1.0, this is what is commonly seen in the Digital Signature Parts:

[SignatureValue]SJfnqZeDHboWDI2n2gWHqTJO5hXvZOFQw8UtDdajktzR40H+W6D
prs5CW/l9A5TF3xcFfyryA3hz7c+0vdlZSnaA+cBn2qPxt7/YmwaAx5Ave
awuach6YPYI123I4I3f58eSMUgPsx6/uuFQFcJltEMw1nWLE6Wb6CPg5OdtXLs=[/SignatureValue]
  [KeyInfo]
  [wsse:SecurityTokenReference]
  [wsse:Reference URI="#SecurityToken-7b5d..."
ValueType="...oasis-200401-wss-x509-token-profile-1.0#X509v3" /]
  [/wsse:SecurityTokenReference]
  [/KeyInfo]
  [/Signature]

Now in WS-Security 1.1 via WSE 3.0, I can do this:

[xenc:CipherData] 
[xenc:CipherValue]n6PnkIWb+QsIeOPehLdtQQKYZn202uGqhN+ShCWyBaCf20rmVcta
Bw2MhB1fv9pE0hOLpAxMMT5ffk4/hnwZ/ef2XcZediF6ySfpse14TI2TGy
cp9XErpeYlZNn1wSchHlOEz2gVYfViZoEOIwn8qR7EofLN3U3Mc5Zp2qG2coI=[/xenc:CipherValue]
  [/xenc:CipherData]
  [xenc:ReferenceList]
  [xenc:DataReference URI="#Enc-0914..." /]
  [xenc:DataReference URI="#Enc-3aab..." /]
  [/xenc:ReferenceList]
  [/xenc:EncryptedKey]
  [xenc:EncryptedData Id="Enc-0914..." Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"]
  [xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" /]
  [xenc:CipherData]  [xenc:CipherValue]RLASn...[/xenc:CipherValue]
  [/xenc:CipherData]
  [/xenc:EncryptedData]

[Signature xmlns="http://www.w3.org/2000/09/xmldsig#"]
  [SignedInfo]
  ...
  [SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" /]
  [Reference URI="#SecurityToken-d217..."]
  [Transforms]
  [Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /]
  [/Transforms]
  [DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /]
  [DigestValue]A0K7OVwZN3vP4rIXfbTZYy+f+ck=[/DigestValue]
  [/Reference]
  [Reference URI="#Timestamp-6f12..."]
  ...
  [/Reference]
  [/SignedInfo]
  [SignatureValue]d8KmXpfspmKiEOZ1eBVY7mk05Wo=[/SignatureValue]
  [KeyInfo]
  [wsse:SecurityTokenReference]
  [wsse:Reference URI="#SecurityToken-32e4..."
ValueType="...oasis-wss-soap-message-security-1.1#EncryptedKey" /]
  [/wsse:SecurityTokenReference]
  [/KeyInfo]
[/Signature]

Note the fonts in RED. There is a new URI: http://docs.oasisopen.org/wss/oasiswss-soap-messagesecurity-1.1#EncryptedKey which ties to a ValueType: A token type of an [xenc:EncryptedKey]

... and more importantly ...

the [SignatureValue] contents is slightly shorter now because it is actually encrypted with a symmetric key now. I know I may be picking here BUT hey, even a single byte in reduction means a lot in throughput performance in terms of wire transfer of documents. .

There are other improvements WS-Security 1.1 brings over its predecessor 1.0, which I will blog more about as I go along.

[1] Just a note to defuse any confusion if it crops up: Asymmetric (Public-Private) key technologies are still very much used in WS-Security and other document-related security specifications today. I dont think it will be dropped anytime soon unless Quantum Cryptography takes off mainstream in a big way or the subtle effects of this reverberates adversely through the security space. Having said that, Symmetric (Master/Session) key technologies have a huge place in the security specifications world too, just by the fact that it is a 1000x faster than much-secure asymmetric ones. Therefore, both technologies co-exist and work very well together in the document security space. To put it simply, a symmetric key (KeyA) is randomly-generated (key-length can be specified by the application - the longer, the better) and then used to encrypt/decrypt messages (MsgA). Once that is done - KeyA is then subsequently encrypted by an asymmetric key (KeyB) and then transmitted through the message. Only the holder of the Private-Key pair of KeyB will be able to decrypt KeyA which can then decrypt/encrypt MsgA.

In Web Services Enhancements (WSE) 2.0, one could exercise some control over what one xml element/fragments wants to encrypt within a soap:Body. Therefore, if I wanted to encrypt the account string in my credit card type, I could do something like this:

[At your Service Side]

Public Class SecuredString
  'Set the Oasis Id that our security reference will point to
  <XmlAttributeAttribute("Id", _
Namespace:=".../2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd")> _
  Public ID As String
  <XmlText()> _
  Public Data As String
End Class

[At your Calling side]

Dim c As SoapContext = a.RequestSoapContext

b.CreditCardType = "VISA"
z.Id = "uri:demoId.softwaremaker.net" 'or some guid
z.Value = "123-456-789"
b.CreditCardAccount = z

c.Security.Elements.Add(New EncryptedData(tok, "#uri:demoId.softwaremaker.net"))

Note: To reduce headache-inducing typo bugs, you may want to use some WSE Constants such as
WSUtility.Prefix
WSUtility.AttributeNames.Id
WSUtility.NamespaceURI

The end result of this is a soap:Body on the wire looks like this:

While I dont know how much of performance benefits this has over one that has the entire SecureCreditCard encrypted (since it is an symmetric-key encryption at its core), I think in terms of latency and throughput, it does offer some benefits especially with a sizable payload (>20-30 kb, for instance ?)

Windows Communication Foundation (WCF, previously - Indigo) does not currently have that feature build in at the moment (Sept05-CTP or known as the PDC-bits). In other words, in WCF today, you encrypt the entire contents of the soap:Body, lock-stock-barrel. I would still love that WSE feature in there: To be able to exercise finer grain control over what I want to or not to encrypt within a soap:Body.

Would really like to find out if I am the only odd one out there. Any users using that existing WSE feature out there that would love to see the same in WCF or do you have other better ideas ? Leave a comment or email me via the contact link on the side. Thank you.

BTW: Whether you encrypt certain elements of the contents or encrypt the entire contents of the soap:Body, both are WS-Security Specifications compliant .
 

Another speaking assignment that landed at my desk is for me to talk about "Web Services Security: How to track along the Security Standards Jungle" on the 21 October 2005

Somehow, I tend to attact the dry topics . This event is owned by OASIS and XMLOne Usergroup. More information can be found here.

If you are around the vicinity, do feel free to drop by and catch up.

Benjamin points to a great tool from MSFT Corp Research in Cambridge that acts as a security diagnosis tool for WSE2 policy files...

Worth trying and looking into even though it is unsupported...Since when is a product or tool that rolls out from Research supported in the commercial production world anyways...

Another +1 for Microsoft for the raising awareness in security, esp in the realms of XML SOAP Services.

SDA-Asia has recently published one of my articles online. In this article, I talked about how Web Services Enhancements (WSE) can be used to solve Real-World business problems with some proper thought and design processes.

This is not as technical an article comparred to the ones I have written before, however, I feel it gives a good overview and insight to what the advanced XML services are and how to make use of some of them to solve some of the business problems of today...and needless to say, WSE 2.0 is THE tool to do that today in .NET

I have spent a fair amount of time writing up a REAL technical article (on WSE, of course) recently which I hope will get published soon enough. Will update all once it goes live. Enjoy.

Finally, this is done. Read the cover story here.

Even though I usually dont advocate the use of SOAP to transfer large BLOBS of binary bits (I tend to think that there are slightly better ways of transferring files and/or attachments), I do believe that there will be more and more calls for uses for it and that is why I think this is an important specification which is way better than W3C's SwA or MSFT Corp's/IETF's  DIME (Can you say Security ?). The latter, incidentally, is being implemented by Web Services Enhancements (WSE) 1 and 2.

Of course, since DIME is being superseded by MTOM, I am really looking forward (hopefully) to the implementations of it in WSE 3.0

William Stacey has outdone himself again. He has blogged on how to create SecurityContextTokens without X509 Certs.

He has beaten me to it. As I have said in a comment to his blog:

...I knew something like that would be very useful and there are tons of requests out there for the use of SCT without X.509 because of cost issues or the server admin doesnt want to install them for whatever reasons.

I was on my way to implementing it, then I took some time off to look at the specifications for the exchange of entropy values, then I got derailed by some work committments and after that I just got lost...

It is so good for you to come up with this. It is excellent. I would have to try it and feedback. Many people will thank you for it.

Julie, if you are reading this, hopefully this will help solve a problem of yours that is way loooong overdue.

I recently extended a chat program written in Web Services Enhancements (WSE) 2.0 utililizing the TCP transport protocol. I wanted it to run over the internet now. This was prompted by some members of our Singapore Professional DotNet Usergroup who wanted to implement a mini Pub-Sub (aka WS-Eventing) project using the tcp protocol.

They had indicated that they had some trouble binding the FQDN specified for the URI in the EndpointReference to a local network interface. If this cannot be resolved, the binding will fail.

At the most basic level, the EndpointReference.Address is both the name of the target and its location. For example, [http://localhost/SomeService] can be used as a name and a transport address. WSE 2.0 comes with an extended model to allow a single named service to be hosted on multiple transport addresses. This can also be useful if we want to apply a single corporate policy on them.

This is where EndpointReference.Via comes in. It allows you to host a well-known service that can only be accessible via different transports such as the soap.tcp protocol of WSE 2.0 and others.

For example, my well-known service is hosted at soap.tcp://softwaremaker.net:2088 (or soap.tcp://219.74.47.214:2088, if you dont have a DNS tagged to it). This is the public FQDN address of the service. For the broadband cable and ADSL users of dynamic IPs, this address may be the address of your home network router.

Now, your WSE 2.0 application has a SOAP Receiver object that allows your application to listen for SOAP requests coming in on WSE2-custom defined transports. Once you define your own address on your own listening machine such as soap.tcp://192.168.2.100:2088/Softwaremaker, you would now have 2 URIs:

Public Facing: soap.tcp://softwaremaker.net:2088
Private Internal: soap.tcp://192.168.2.100:2088/Softwaremaker

The Public Facing well-known URI becomes the EndpointReference.Address while the transport address mechanism becomes the EndpointReference.Via

In other words, soap.tcp://192.168.2.100:2088/Softwaremaker will listen for any messages that is sent to soap.tcp://softwaremaker.net:2088 (the address element in the WS-Addressing headers). Put it in another way, the custom soap.tcp transport will only accept messages sent to soap.tcp://softwaremaker.net:2088 if they arrive via the internal address:192.168.2.100.

The Via address is not in the message itself, only the well-known URI is. Based on the network address the message is being received on, the custom soap.tcp transport mechanism will know how use both well-known and private URIs to dispatch the message to the registered and configured-properly SOAP Receiver.

    EndpointReference EPR = new EndpointReference
    (new Address(new Uri("soap.tcp://softwaremaker.net:2088")),
    new Via(new Uri("soap.tcp://192.168.2.100:2088/Softwaremaker")));

    SoapReceivers.Add(EPR, yourOwnSoapReceiver);

The last step you need to take is to be able to forward all requests going to the well-known URI (soap.tcp://softwaremaker.net:2088) to your local machine with the internal IP 192.168.2.100:2088

This is not something you can do in WSE 2.0 or in your machine. This has to be done at your broadband or cable router. You just have to forward requests coming in to your Public port:2088 to the Private port:2088 of machine 192.168.2.100 (Note that these ports doesnt have to be the same number at all)

Of course, the huge assumption is that you have control over the port routing and forwarding of your broadband or cable router (which may be rather tricky if you are within a corporate or organizational boundary) BUT technically, you will be able to carry out a p-2-p SOAP message chat or even do a Pub/Sub model approach with your own implementation of the “Notification” and “Solicit-Response” message-exchange patterns over the internet using the custom soap.tcp protocol of WSE 2.0

[Author Note] What do ya know ? I just found that that Hervey has got an even better post on the EndpointReference.Via of WSE 2.0 here.

William Stacy has a new blog in MSN Spaces and he blogged about a topic that has spurned from recent activities in the WSE newsgroups.

It is about the security and the use of username tokens in the real world, specifically when it relates to passwords being stored as hash in the user database.

William proposes a method here to solve the issue of how to authenticate username tokens embedded in _WS-Security Specs_ security headers.

In my own opinion, his case represents a very major common representation of how passwords are stored in the database. They are mostly and SHOULD be hased. To add another realm of security, SALT is used. However, I dont really agree that his method may prove to more secure. In fact, I think it gives a somewhat false sense of security (and William, please correct me if I am wrong anywhere).

1)   By using your verifier as a matching mechanism to gain authentication, then this verifier (SALT Hash and all) effectively becomes a password. If Mallet steals the hash from the user database, nothing prevents him/her from writing a client that sends the hash and thus he would authenticate successfully. This is exactly what the hash scheme is trying to avoid in the first place.

If used this way, the hash is no safer than storing the passwords in clear text in the database...which ultimately means that the weakest link is still the security of the Username Database which must be protected at all costs.

In other words, this must be made known clearly so that it doesnt preach a false sense of security that people think that this scheme NOT only protects their cleartext password BUT also their SOAP calls as well.

This post here explains real well on my thoughts as well.

2)   SALT should be a completely random value and should be algorithmically introduced to further obfuscate the one-way hash. In your approach, it seems that the SALT is tied very much to your username (am I wrong ?). This doesnt help much because I dont need to guess your publicly-available username, there are only a handful of hashing algorithms out there and you are NOT passing any SALT into your PasswordDeriveBytes constructor. In fact, the only saving grace is the iteration count which basically sets the number of iterations for the operation. Is that enough ? I believe it may serve well for some smaller-scale simpler systems BUT I dont know how it sits well with some of the security policies of bigger enterprises.

IMHO, I think the current username tokens as defined by WS-Security doesnt fit very well into most EXISTING user databases which store passwords as hashes which may or may not be SALTED. I dont think there is a clean way to do this in WSE without using or representing the hashes as passwords. However, I am still thinking about this issue and will blog more about it later if (not when) I reach enlightenment.

Your approach, however, does allow passwords to remain as they are in the EXISTING user databases. The only obstacle you require is a change in the schema of that table, which requires management approval and buy-in and usually triggers off many other related procedures, and that in my experience, is sometimes harder than finding the password from a hash.

[Author Note]: This topic has got nothing to do with the security of username tokens as I have blogged about earlier here. This is all about the authentication of username tokens with the stored credentials in the user databases.

After installing Web Services Enhancements (WSE) 2.0 SP2, the most natural thing for me to do is to run my previous WSE 2.0 SP1 projects and see if it works with the new assembly.

Most of it still do run <phew>. A couple of them (specifically the SOAP Routing ones) did NOT run as intended. A further drilldown into the code revealed that the ExtendedSecurity doesnt serialize properly if you are planning to send another set of Security Headers to the next SOAP node...In fact, it doesnt get serialized at all.

...Obviously, this next node cannot be the ultimate soap receiver as target service cannot process 2 security headers as specified in the _WS-Security Specs_. You can refer to my previous discussions with HerveyWhere and here.

So, if your next node is another SOAP Router and you need a different set of Security Headers for the next node to process, this is how to do it with the ExtendedSecurity function in SP2:

You need to add a Security Utility Timestamp into the Security Header in order for the ExtendedSecurity function to serialize a new set of Security Headers properly.

Dim t As Utility.Timestamp = AnotherSecurityHeaderBlock.Timestamp

Thereafter, when you call the ExtendedSecurity function and add this new Security Header block, the serialization will take place.

In SP1, it is NOT necessarily for you to add this timestamp.

The WSE team has confirmed this as a workaround to this minor bug.

With reference to my earlier post here, I had explained how we can encrypt the Usernametoken element <wsse:UsernameToken> if we choose to use the PasswordOption.SendPlainText enumeration, for real-world reasons such as

• Windows Authentication
• Passwords are stored as Hash in the UserDB

Other elements in the <wsse:Security> Header element can be encrypted too, although great care and design must be taken as it may reduce the extensibility of SOAP Headers through routing intermediaries. One of them is the <Signature> element.

As I had explained in another post here, digital signatures can and may be verified for authentication and trust by any SOAP node. If the <Signature> element is encrypted, we may be preventing any SOAP intermediary from authenticating and verifying the digital signature. Unlike digital signatures, <xenc:EncryptedData> elements are encrypted for a specific receiver in mind and therefore, only that one party SHOULD be able to decipher it with a corresponding Private key or shared secret. SOAP intermediaries, trusted or not, SHOULD NOT be able to decrypt or view the the encrypted content(s) and therefore cannot authenticate and verify the signature.

However, if one should decide that their dispatching mechanism is based on a non-intermediary route or if the <Signature> element may not be meant for the ultimate SOAP receiver and therefore can be removed by the SOAP intermediary, this can be done easily as well with WSE 2.0.

The key is to create a MessageSignature on its own and assign it an ID. Here is the code snippet on how to implement it:

And the wonderful result that comes out from the oven: (geez...I need a life )

<wsse:Security soap:mustUnderstand="1">
<wsse:BinarySecurityToken ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" wsu:Id="SecurityToken-e8f64eea-1d63-4db2-943c-9bfb5dfccbfc">MIIBxDC...du2fPMER8ajJfl</wsse:BinarySecurityToken>
<wsse:UsernameToken wsu:Id="SecurityToken-3370d9ae-deb9-4a01-9b9c-c8dd072568fa">
<wsse:Username>ABC</wsse:Username>
<wsse:Nonce>Amx9amrLXR02etJLsNwdwA==</wsse:Nonce>
<wsu:Created>2004-12-11T07:38:33Z</wsu:Created>
</wsse:UsernameToken>
<xenc:ReferenceList xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:DataReference URI="#EncryptedContent-0e6936bf-67a5-48a5-ba8a-d9ba6141e75f" />
</xenc:ReferenceList>
<Signature Id="2c091bb3-bcdc-4da1-97c5-dcd60dac7312" xmlns="http://www.w3.org/2000/09/xmldsig#">
<xenc:EncryptedData Id="EncryptedContent-0e6936bf-67a5-48a5-ba8a-d9ba6141e75f" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<wsse:SecurityTokenReference>
<wsse:Reference URI="#SecurityToken-3370d9ae-deb9-4a01-9b9c-c8dd072568fa" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken" />
</wsse:SecurityTokenReference>
</KeyInfo>
<xenc:CipherData>  <xenc:CipherValue>rFfJS87yAdFFkW1dVbot...tJ+9U8+CU5qsI=</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</Signature>
</wsse:Security>

Voila! The Red bold font will show that the Signature Element is now encrypted.

To slightly expand on my post and Hervey's a little bit further, there was mention on the use of Enveloped Signatures in the SOAP Headers. Enveloped Signature (as defined by XML-Digital Signature) is a signature over the XML content that contains the signature as an element. The content provides the root XML document element. Obviously, enveloped signatures must take care not to include their own value in the calculation of the SignatureValue. In other words, Enveloped Signature would sign the contents of the SOAP headers WITHOUT the signature. This is the only way a Security header can be signed without creating a circular reference dependency.

To do the above, you are enforcing the prevention of intermediaries from modifying the SOAP Headers.

However, as taken from the _WS-Security Specs_

WS-Security doesnt *believe* in the Enveloped Signatures because it stands on the belief that SOAP Headers are mutable. Since SOAP Headers can change and the likelihood is there that a SOAP intermediary can change the headers, an Enveloped Signature would not be as extensible and work as well.

I am a strong believer of that. If a normal signature is used instead of an enveloped one, then an intermediary can safely add more tokens and more signatures to a Security header targeted at another node on the message path...and that is why there is WS-Security. Security cannot just be based on End-to-End scenarios or else SSL / HTTPS will suffice.

I also further believe that an intermediary should be able to extend Security headers which are meant for other target nodes. Since a SOAP node can only process a single Security Header (because of re-ordering constraints of SOAP Headers), this option may not be as far-fetched or ridiculous as it may sound.

Of course, anyone can still choose to implement Enveloped Signatures over their SOAP Headers if they are just implementing End-to-End scenarios and enforcing non-tampering measures over any desired or un-desired intermediaries. However, extensibility may not be an option here should intermediaries be required to offload certain processing functionality off the ultimate receiver or even add more tokens and signatures along the way.

I have been noticing an increasing number of emails and newgroup threads asking for the security of Usernametokens as specified by _WS-Security Specs_ on OASIS. Most people would like to use it because it is the only alternative they have and there are no other options for using X.509 PKI Digital Certificates. Here is my personal take on it.

I think some of the security concerns are slightly misplaced here. Firstly, I dont think WS-I or OASIS would include Usernametokens inside the WS-Security Specifications if they doubt its security. As I would like to say, --- Implementation is key.

A Username token does NOT use any simpler or less-standard security algorithm than any other tokens. In fact, it uses the same hashing algorithm, symmetric algorithm such as the 128-key Cipher Block Chain (cbc) Advanced Encryption Standard, etc as any other token. Many people, also, do not realize that the same symmetric algorithm is used to encrypt the SOAP message body when an asymmetric X509SecurityToken is used as well. The asymmetric key algorithm is only used to encrypt the secret key that is doing the actual symmetric encryption processing. This is done for the purpose of reducing cipher bloat and increasing processing speed. The paranoia in me, however, would go for a higher-bit key implementation, which is possible.

Remember that your secret can be stolen and kept for years and tried to be broken with much higher-end and cheaper deciphering machines in the future. OK, OK, that is my paraniod self talking.

I believe when statements are made against the security of Usernametokens, they are made against the passwords of the Usernametokens. Therefore, the statement: "Usernametokens, on their own they are only as secure as the passwords"

Usernametokens are as secure as your passwords. That means that if you have a good security policy on how your company treats passwords, ie...

1. Minimum password length
2. Implementation of alphanumeric and other different characters and symbols in password
3. Password change frequency (in months instead of years )
4. Elimination of Weak Passwords such as using names and such
5. ...

you should NOT be so fearful of using a Usernametoken in your Web Service implementation.

On the other hand, if you don't treat or administer your passwords with good password policies, then you cannot expect Usernametokens to give your message as secure a protection as you would like.

I would also recommend using the PasswordOption.SendNone, if possible. The hash of the password and other elements are used to produce the cipher. NO password is sent over using this enumerated option. Of course, the only caveat is except through a dictionary attack, which of course, can be made so much more difficult (or almost impossible) by having a good password policy administration system.

If you have to send your Usernametoken over in PasswordOption.SendPlainText for whatever reasons (using Windows, LDAP Authentication or you may have hashed versions of your passwords stored in your UserDB), you SHOULD encrypt the UsernameToken with a X.509 digital certificate. Read my post here for my own implementation of it.

Another thing to take note is one that relates to the real world and why I believe Usernametokens have its place here. It is easiest to implement and common in any business environments. Therefore, it can be plugged into any existing IT systems with relatively lesser effort. Also, X509 digital certs are usually used to authenticate machines and / or companies, it would be more expensive and unrealistic to expect every user in a 100+ user organization to have a digital cert and a private / public key pair. Therefore, I strongly believe that Usernametokens are more appt to authenticate the users themselves in the real world and will continue to be one of the most popular way to authenticate users in the near biometric-less future. However, if you are using authentication between machines, you should opt for X509 digital certs instead.

• For security reasons, it is strongly recommended to encrypt Username tokens, especially when they contain password information. The SecurityTokenServiceClient class now automatically encrypts any UsernameToken security tokens included in outgoing SOAP requests. Similarly, the SecurityTokenService class automatically encrypts any UsernameToken security tokens included in outgoing SOAP responses.

For all those wanting to do WS-ReliableMessaging today with WSE 2.0, you can check out what Andrés has done here.

I have noticed Rich Salz's absence for a rather long time and he comes back to give WSDL 2.0 a kick in the head.

Looks like I have to reserve my comments until I read through those specs.

Frankly though, I am rather disappointed with the handling of the later XML Services Specs by W3C and this is not just the beef I have to pick with W3C.

W3C's definition of SOA goes like this:

“A set of components which can be invoked and whose interface descriptions can be published and discovered”

Hell, why not they just say its XML Web Services ? This is just a plain crappy, poorly thought of definition.

And it contributes to all the market mis-definitions of _SO(A)_ where the terms SO(A) and XML Web Services, although tightly-linked, are NOT synonymous.

I came across some questions pertaining to how the asymmetric keys of X.509 PKI Digital Certificates are being transmiited during SOAP Message exchanges for both XML-Encryption and XML-Digital Signature.

There seems to be some sort of slight confusion here so I will explain in a more user-friendly fashion here.

Although XML-Encryption and XML-Digital Signature works on the same fundamental principles, they are implemented rather differently. I will not go into details on how they work on top of Factoring, Prime Numbers and such as these are topics that will not fit into one blog post. You may want to go here to find out more. To put it simply:

1. If Alice wants to encrypt a message just for Bob, Alice will encrypt the message using Bob's (Publicly-available) Public Key, which, Bob's (Secretly-held) Private Key can decrypt once he received the message
2. If Alice wants to sign a message, Alice will encrypt the message using her (Secretly-held) Private Key and then anyone with Alice's (Publicly-available) Public Key will be able to verfy that the message was authentic and signed by Alice only.

If you scrutinize these 2 key principles enough, you will realize that there is a key differing implementation detail.

Now, lets go into how WSE 2.0 implements OASIS WS-Security Specifications riding on top of ASMX XML Web Services.

To be true to myself and how I would try to use the term XML Services whenever I can, I would also avoid the use of client-server whenever I can and use the term Publisher-Subscriber instead.

For simplicity's sake, I assume the following:

• [PublisherCode] is always going to return "Hello World"
• [PublisherCode] Response Stream is just going to be plain simple vanilla message with NO fat and trimmings
• ONLY X509 Asymmetric Encryption Public Private Key Pairs are used here
• Alice is the Subscriber while Bob plays the role of the Publisher

For Scenario 1 XML-Encryption

[SubscriberCode]

Dim a As IndexWse =New IndexWse

Dim store As X509CertificateStore = _
X509CertificateStore.CurrentUserStore(X509CertificateStore.OtherPeople)
store.OpenRead()

Dim cert As X509Certificate = store.FindCertificateByKeyIdentifier _
(Convert.FromBase64String("bBwPfItvKp3b6TNDq+14qs58VJQ="))(0)
Dim xTok AsNew X509SecurityToken(cert)

a.RequestSoapContext.Security.Elements.Add(New EncryptedData(xTok))

MessageBox.Show(a.HelloWorld)

[Resultant Request SOAP Message in brief]
...
  <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
  <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
  <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
  <wsse:SecurityTokenReference>
  <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509 

SubjectKeyIdentifier">bBwPfItvKp3b6TNDq+14qs58VJQ=</wsse:KeyIdentifier>
  </wsse:SecurityTokenReference>
  </KeyInfo>
  <xenc:CipherData>
  <xenc:CipherValue>XFMDuiWzvjOVA9k FThrkUo=</xenc:CipherValue>
  </xenc:CipherData>
  <xenc:ReferenceList>
  <xenc:DataReference URI="#EncryptedContent-e8284f45-0a66-409d-a5e2-c041b648fbac" />
  </xenc:ReferenceList>
  </xenc:EncryptedKey>
...

[Comments]
Since Alice is encrypting something specific for Bob's eyes only, Alice need to explicity get Bob's (Publicly-available) Public Key. This has to be an explicit assumption to make. This can be done in many ways which traditionally make take some out-of-band approach. In our case above, Bob's Public Key is installed on my machine in the CurrentUserStore\OtherPeople key store. Bob can then use his (Secretly-held) Private Key to decrypt the cipher in the message. This is a very end-user specific approach. It is unlikely Alice will be encrypting something that she wants the whole world to see. Therefore, the Publisher (Bob) can be sure that the X509 SubjectKeyIdentifier of "bBwPfItvKp3b6TNDq+14qs58VJQ=", which contains his (Secretly-held) Private Key, can be found in his key store of the machine. It would be a fairly safe assumption to make.

For Scenario (2) XML-Digital Signature

<WebMethod()> _
PublicFunction HelloWorld() AsString

Return"Hello World"

EndFunction

[SubscriberCode]

Dim a As IndexWse =New IndexWse

Dim store As X509CertificateStore = _
X509CertificateStore.CurrentUserStore(X509CertificateStore.MyStore)
store.OpenRead()

Dim cert As X509Certificate = store.FindCertificateByKeyIdentifier _
(Convert.FromBase64String("gBfo0147lM6cKnTbbMSuMVvmFY4="))(0)
Dim xTok AsNew X509SecurityToken(cert)

a.RequestSoapContext.Security.Tokens.Add(xTok)
a.RequestSoapContext.Security.Elements.Add(New MessageSignature(xTok))

MessageBox.Show(a.HelloWorld)

[Resultant Request SOAP Message in brief]
...
  <wsse:BinarySecurityToken ValueType=" http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 "

EncodingType=" http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary "

wsu:Id="SecurityToken-7b5d8096-928a-45d2-b504-d0bfb84eab41">MIIBxDCCAW6gAwIBAgIQxU PYdu2fPMER8ajJfl</wsse:BinarySecurityToken>
 
  <Signature xmlns=" http://www.w3.org/2000/09/xmldsig #">
  <SignedInfo>
  <CanonicalizationMethod Algorithm=" http://www.w3.org/2001/10/xml-exc-c14n #" />
  <SignatureMethod Algorithm=" http://www.w3.org/2000/09/xmldsig#rsa-sha1 " />
  <Reference URI="#Id-f7e1c0fa-e3da-4cb4-be53-f583153bc588">
  <Transforms>
  <Transform Algorithm=" http://www.w3.org/2001/10/xml-exc-c14n #" />
  </Transforms>
  <DigestMethod Algorithm=" http://www.w3.org/2000/09/xmldsig#sha1 " />
  <DigestValue>avMezj5NhZwNerXidi5oBmjqi/g=</DigestValue>
  </Reference>
  ...
  </SignedInfo>
 

<SignatureValue>JfnqZeDHboWDI2n2gW =</SignatureValue>
  <KeyInfo>
  <wsse:SecurityTokenReference>
  <wsse:Reference URI="#SecurityToken-7b5d8096-928a-45d2-b504-d0bfb84eab41"

ValueType=" http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 " />
  </wsse:SecurityTokenReference>
  </KeyInfo>
  </Signature>
...

[Comments]
If you look closely at the subscriber code, you will notice a few differences. First, Alice is using her (Secretly-held) Private Key to sign the message. Then she attaches the X509 Digital Certificate to the message. WSE2.0 is smart enough to know that ONLY the Public-Key pair of the X509 Digital Certificate goes out in SOAP on the wire. This is encapsulated in the <wsse:BinarySecurityToken> element in the SOAP Header. Why the difference ? Because a signed message by Alice is for any and everyone to verify and therefore Alice cannot assume that any and everyone has got a copy of her Public Key. In this case, she has to attach her Public Key in the X509 Cert to her SOAP Request Message so that anyone getting hold of her Public-Key can verify that ONLY she (Alice) can sign the message. The <wsse:BinarySecurityToken> element, in this case, actually contains a Base64 Binary Respresentation of Alice's Public Key X509 Certificate.

Now, can you spot the hack here ?

If Mallet of Man-In-The-Middle chances upon this message, he can actually signed the SOAP Message elements with his (Secretly-held) Private Key. Then he can replaced Alice's <wsse:BinarySecurityToken> element with his own Base64 Binary Respresentation of Mallet's Public Key X509 Certificate. If Mallet succeeds in doing so, and this can be fairly straightforward and easy to implement (I may blog about how to do this in a later post), the SOAP Message received is actually cryptographically verified to be accurate even though the trust has failed because of the Untrusted Public Key.

So, what can Bob do ? Well, Bob has got 2 choices BUT both require some out-of-band communication with Alice. There has to be some kind of communication work done before trust can actually be established. You really cannot run away from it.

1) Bob can implement a Trust Verification at the Application Layer

<WebMethod()> _
PublicFunction HelloWorld() AsString

Dim xtok As X509SecurityToken = GetSigningToken(RequestSoapContext.Current)

If xtok.Certificate.GetCertHashString = RetrieveFromListofTrustedThumbPrints
OR
If xtok.KeyIdentifier.Value = RetrieveFromListofTrustedKeyIdentifiers

Return"Hello World"

Endif

EndFunction

PublicSharedFunction GetSigningToken(ByVal context As SoapContext) As SecurityToken
Dim element As ISecurityElement
ForEach element In context.Security.Elements
If (TypeOf (element) Is MessageSignature) Then
' The context contains a Signature element.
Dim sign As MessageSignature = element
' The SOAP body is signed
Return sign.SigningToken
EndIf
Next
ReturnNothing
EndFunction' GetSigningToken

[Comments]
As you can see, the message is allowed through and Bob checks it at the application level. He can either verify via the Digital Certificate's Thumbprint which is exposed via the GetCertHashString property or the Digital Certificate's KeyIdentifier which, in this case, happens to be "gBfo0147lM6cKnTbbMSuMVvmFY4=" One drawback on this method is that message is allowed through to the application layer and certain resources are invoked to check for the trust of the sender.

2) Bob can implement a Trust Verification at the WS-Policy Level

<WebMethod()> _
PublicFunction HelloWorld() AsString

Return"Hello World"

EndFunction

[WS-Policy File in brief]
...
  <request policy="#Sign-X.509" />
  ...
  <policies xmlns:wsu=" http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd "

xmlns:wsp=" http://schemas.xmlsoap.org/ws/2002/12/policy " xmlns:wssp=" http://schemas.xmlsoap.org/ws/2002/12/secext "

xmlns:wse=" http://schemas.microsoft.com/wse/2003/06/Policy "

xmlns:wsse=" http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd "

xmlns:wsa=" http://schemas.xmlsoap.org/ws/2004/03/addressing ">
   <wsp:Policy wsu:Id="Sign-X.509">
   ...
   <wssp:Integrity wsp:Usage="wsp:Required">
   <wssp:TokenInfo>
   <wssp:SecurityToken wse:IdentityToken="true">
   ...           

<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3</wssp:TokenType>
   <wssp:TokenIssuer>CN=Root Agency</wssp:TokenIssuer>
   <wssp:Claims>
   ...
   <wssp:SubjectName MatchType="wssp:Exact">CN=WSE2QuickStartClient</wssp:SubjectName>
   <wssp:X509Extension OID="2.5.29.14" MatchType="wssp:Exact">gBfo0147lM6cKnTbbMSuMVvmFY4=</wssp:X509Extension>
   </wssp:Claims>
   </wssp:SecurityToken>
   </wssp:TokenInfo>
   ...
   </wsp:Policy>
  </policies>
...

[Comments]
As you can see, this method is so much cleaner and neater. Messages will fail at the Policy Pipleine level and will NOT reach Bob's application code itself. See that the HelloWorld WebMethod has no extra trimmings and fat. The policy file dictates that the X509 Digital Certificate coming in must have SubjectName = CN=WSE2QuickStartClient AND KeyIdentifier = gBfo0147lM6cKnTbbMSuMVvmFY4=

If the SOAP Requests carrying the <wsse:BinarySecurityToken> element doesnt meet these policy demands, an exception is thrown. Beautiful ! Of course, technically speaking, resources are still being invoked to check for these demands but they happen at the policy-assertion level of the WSE pipelines which are abstracted away from the developer, thus allowing these developers to focus on the business logic itself. Application code is definitely cleaner and more maintainable.

Both methods, though slightly different, work on a major principle of assumption that Alice and Bob have established some kind of communication channel between them or amongst others where Trusted KeyIdentifiers or Thumbprints are exchanged. It also highlights the fact on how important having a common trusted root Cert Authority that can be verifiable such as Verisign or Checkpoint is.

This blog post, long as it is, highlights some major points. We dont live in a secure world and this is the only thing we can assume safely. Verifying a signed message is NOT as simple as it may seem. There has to be some kind of out-of-band approach to ascertain trust between partners because validation of the message, as we can see from the above example, is definitely NOT enough.

Some of the (W3C) SOAP specifications that relates to the implementation and optimizing of the transmission and/or wire format of SOAP messages, namely

• XOP
• MTOM
• RRSHB

have reached the Proposed Recommendation Stage of W3C.

My previous blogs on WS-* Specs