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 ...

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 !

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:

---

[wsse:Security soap:mustUnderstand="1"]
...
[wsse:BinarySecurityToken ValueType="...oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="...wss-soap-message-security-1.0#Base64Binary" wsu:Id="SecurityToken-76ae..."]MIIBvD...[/wsse:BinarySecurityToken]

[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.