Wednesday, December 29, 2004
Mike Champion has a great post here on the overheads of XML.
IMHO, I think a binary representation of XML brings on a whole different set of issues, namely removing the abstraction it is supposed to represent.
On a slightly different perspective and from a designing front, I have been advocating against the use of XML in all layers of a enterprise application esp. when tightly bound object technology is much more desired. In my presentations on SO(A), I have always preach on best using service-messaging as communication b/w applications, NOT between tiers of an application.
However, many businesses are using XML Services as a communication mechanism JUST SO they can be seen as implementing an SO(A)... and of course, for all the wrong reasons.
Hence, many of them complain when performance suffers.
What do they expect when they are making verbose, chatty calls to their own Data Access Layer via SOAP ?
Tuesday, December 28, 2004
Some people I spoke to in the US and Europe still cannot comprehend the drastic devastation of the Asian earthquake and Tsuamis. I like how William Rees-Mogg puts it across in his article on the Times.
“...The earthquake itself is said to be 1,000 kilometres (620 miles) in length; the seabed was opened up as though by a zip fastener; this event threw up a gigantic wave three storeys high, which travelled for thousands of kilometres...”
“...If such an earthquake happened in Europe, we would be able to trace the fault from London to Rome, or to Berlin...If a tsunami ten metres high stormed its way up the Thames, half of London would be under water. If such an earthquake ripped through the San Andreas fault in California, it would virtually tear the state in two, and cause trillions rather than billions of dollars of damage...”
The quake is caused when the Indian plate moved into the Burma plate. There is said to be a 1000 times more energy released from this compared to the devastating Kobe Earthquake in Japan in 1995. In fact, this has caused some of the lands and islands in South Asia to move and may need a redraw on the map. This should give people an idea of how huge the swells and Tsunamis were.
In my earlier post here, I mentioned that Singapore was spared by the physical shock of this earthquake and Tsunami...however, Singaporeans are NOT spared.
So far, 7 and counting have died. All holidaying and visiting in Sri Lanka and Phuket. 450 Singaporeans are in Phuket at that time and hundreds of holidaying Singaporeans are still not accounted for from Malaysia, Thailand to the Maldives.
There are so many holidaying foreigners in Phi Phi Island of Thailand who have been killed or missing as well. Most of them are beachgoers and surfers catching the what-were-once the beautiful southern beaches of Thailand.
What also was very sad is that there are reports of many women and children who drowned on the shores of Aceh, Indonesia. They had noticed that unusual low tides and had rushed out in hordes to admire the beautiful low-lying corals. What they didnt realize is that this is usually a sign of a fast impending approach of a major seismic wave as it gathers its energy for a major strike. Fishermen at shore, who knew about the symptons of receding water to be a sign of an approaching tsunami, were too late in warning their wives, children and other people. The entire shoreline of Aceh, Indonesia is destroyed in this disaster.
“...If the trough of the tsunami wave reaches the coast first, this causes a phenomenon called drawdown, where it appears that sea level has dropped considerably. Drawdown is followed immediately by the crest of the wave which can catch people observing the drawdown off guard...”
“...As a tsunami nears the shallower water close to the shore, the viscous drag of the continental shelf slows the front of the wave. The first sign of an approaching tsunami is usually a significant retreat of the sea. As a result, the trailing waves pile on top of the waves in front of them (like a rug crumpled against a wall), thereby significantly increasing the height of the wave before hitting the shore. Although a tsunami advances much slower as it approaches land, its momentum is powerful enough to flatten houses, buildings and trees and carry ships far inland...”
We also should not forget that there are so many bodies that have been washed out to the Ocean, probably not to be found, leaving many affected families and relatives grieving for the missing...a death with no confirmation of a body. I dont know if there are any griefs in the world that can be more painful than that.
While watching the footage of the scenes of destruction on TV, while heart-wrenching as it is, it is heart-warming to see people of all colors and races carrying each other and helping each other out. Nobody cares what you are, who you are, where you are from or what your beliefs and ideals are.
For me, for that one moment, the entire world unites.
Monday, December 27, 2004
I had a chat with Julie Lerman this morning about the Asia Quake that killed thousands with its unprecedented Tsunamis. It is important to note that Tsunamis are NOT tidal waves as it is not caused and has nothing to do with tides. It is actually seismic waves caused by earthquake or volcanic activites. This was the largest earthquake in the world in the past 4 decades with an 8.9 on the Ritchter scale. Coastal places like Phuket, Maldives and Sri Lanka were hard hit with fishermen villages and holiday makers.
Here in Singapore, we are very lucky to be protected by a big land mass called Indonesia. So all we felt here are slight tremors that just shook hanging lights. Things would be bad if the Tsuanmis were to hit from the other side...with our small island state and many tall buildings, a 30 footer would wash our city center right into the sea...
With all the da** violence happening in Thailand, India and Indonesia, all it takes it an act of God and thousands are killed...doesnt matter what color or race you are, whether you are muslim or not, or whichever tribe you are from...
People still dont understand after all these years of civilization...<sigh>
Julie emailed me right on the onset of receiving the news and worrying for her friends in Chennai (prev known as Madras). Her blog is also the first out of so many technical blogs I read that posts news about this. Being so involved with INETA, she has contacts and friends all over the world.
With all these tragedies caused by these calamities, it is definitely nice to find gems in friends like these, no matter how distant they are and it tends to bring out the best in people and human nature.
It is just very disturbing to see that it takes a disaster to bring that out...
Friday, December 24, 2004
According to this article, it says that
- Web services, security and Linux jobs continue to dominate the IT help wanted ads and are projected to remain among the hottest skill and certification areas in 2005, according to research firms that specialize in tracking skills and certifications...
- ...Networking, messaging and programming language skills also increased in value...
- A small drop off in offshore outsourcing projects and an increase in competition for IT consulting talent have contributed to a reversal in declining premium pay tied to IT skills
I guess the bold font equates to good news for me BUT can only be realized if all employers and companies recognize that as well...
This is a Godsend. Will refer to it before installing the Longhorn Client HEC Build 4074 on my VPC to churn out some Indigo stuff.
Excellent resource !!!
I owned a 2.5 inch 40 GB Harddisk (USB2 interface), then the VPC images started taking its weight in there...
...then moved on to buy a 2.5 inch 60 GB Hitachi Travelstar Hard-disk (5400 rpm 8 MB cache) to store all additional files and images...
...Last night, just bought a 3.5 inch Maxtor DiamondMax 10 Hard-disk Drive (7200 rpm with 16 MB cache !!! ) with a cool fan-cooled casing to boot...all for SGD340.00 (equiv to USD207++ at today's exchange rate)
Cool, 16 MB Cache !!! ...what I always wanted. (actually what I wanted is the 256 MB cache, but the technology and price, probably, will be beyond my reach for some time to come...)
However, mine is the parallel ATA IDE interface which transfers external data at 133MB/sec, teeny-weeny bit slower than the Serial ATA interface which transfers at 150MB/sec.
Read some of the product specs of the DiamondMax 10 here.
A piece of advice for those shopping for these items:
- Do NOT get a 8MB cache for hard-disks drive >= 200 GB. It is safer to get one with 16 MB cache. And the price difference is only a few SGD dollars. Well worth the investment for better reliability.
- Go for a fan-cooled casing instead of an aluminium casing. Yeah, I know the aluminium casing looks cool, weighs lighter and can dissipate heat...BUT a fan-cooled plastic casing dissipates heat better and it is unlikely you are going to carry your multi-gigabyte hard-disk casing and show it off at your nearest Starbucks.
Monday, December 20, 2004
I constantly ranked Scott McNealy of SUN Microsystems as one of my all-time favourite speakers and I had always try to catch him speak whenever he is here in Singapore.
His brashness showed again when he criticized a significant detail of how Oracle sells its software based on how many processor core a machine has...and he did it at Oracle's own OpenWorld conference. What a guy...
“IBM, Sun, Intel, Advanced Micro Devices and others have begun a move to dual-core chips--designs with two processing engines on the same slice of silicon--and are headed down a path for even more cores. That has triggered a pricing debate for software companies: Should the charge be per chip socket or per processor core?”
It is interesting to note that even when software companies, on the other hand, stand to lose revenue using the per-socket definition, MSFT Corp prefers a per-socket pricing.
This strategy means it will have a cost advantage over its competitors when dual-core processors emerge that can run Microsoft SQL Server.
Sunday, December 19, 2004
Another good XML Learning Resource TopXML has built the XML News Reblogger. As quoted here on their Website:
“Reblogger is a free aggregator service provided by TopXML. We collect XML blog items four times a day from around the web, so that you can view all the most interesting and most useful news right here in our reblogger. Enjoy
View the blogs and feeds we fetch...”
Having been developing for a number of years since the late 80s, I have been very used to the programming practice of using hungarian notation. I not only used it in variables, but in the database naming as well. Yes, I used tbl and fld prefixes for my Tablenames and Fieldnames respectively.
Of course, recent recommendations is to dump hungarian notation in your programming style and opt to use meaningfull, descriptive words instead. I have also been poked fun at for using hungarian notation while doing some testing work for Paladin by its author.
So there I decided to adopt a new developing and programming lifestyle and was happily humming along when I got hit face-first by a (JET Engine) ADO.NET Exception Syntax error in UPDATE (0x80040E14). Having been doing the same UPDATE statement style and using the same Data Access Layer blocks for so long, the ego-monster in me looked for a system bug right away. Running this same query within MS Access itself would be fine but if I used JET as the Data Provider, the same exception would occur. Try as I have to google'd it, I cannot seem to find out what was wrong. Most of them poined to the use of JET's keywords such as [PASSWORD] which I have learnt from previous experience to just use PWD. Here is my “post-hungarian notation” UPDATE Statement:
"UPDATE LibraryItems SET Title = '" & psTitle & _
"', AuthorArtist = '" & psAuthorArtist & "' , ItemTypeID = " & piItemTypeID & _
" , GenreID = " & piItemTypeID & " , ContentFormatID = " & piContentFormatID & _
" , Qty = " & piQty & " , DateBought = #" & pdDateBought & "# , PriceBought = " & _
pcPriceBought & " , DateSold = #" & pdDateSold & "# , PriceSold = " & _
pcPriceSold & " , StatusID = " & piStatusID & " , References = '" & psReferences & _
"' , Remarks = '" & psRemarks & "' WHERE ID = " & CommonUtil.ValidateSQLSafeString(mRecID)
Can you spot my mistake ? I didnt until I stumbled across this MS Support article about JET's reserved keywords...
AARRGH !!! So, REFERENCES is a JET's reserved keyword as well. In the past, I would have used fldReferences and therefore would NOT have encountered such an exception.
The FIX: Wrap Square brackets around the column name [References]. In fact, I recommend to wrap it around all column names, not just suspect ones. OR just use the CommandBuilder QuotePrefix and QuoteSuffix command to bypass the reserved keyword error.
- CommandBuilder.QuotePrefix = "["
- CommandBuilder.QuoteSuffix = "]"
Tuesday, December 14, 2004
Monday, December 13, 2004
It is amazing who is getting the definitions of WSDL wrong and how they are getting it wrong...
Check these screenshots out and see the sites where they are posted at:
- Website of IBM > Web Services Declaration Language ?!?
- Website of VSJ UK - Web Services with JAX-RPC > Web Services Discovery Language ?!?
- Website of W3C > Web Services Definition Language ?!?
If you think this site looks OK to you...Well, Web Services Description Language is definitely correct ... BUT look again at the title of the page...
I am not kidding. A friend referred me to this site . Try it at your own risk though.
Saturday, December 11, 2004
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:
Dim a As New MessageSignature(yourSignatureToken)
Dim g As Guid = g.NewGuid
a.Signature.Id = g.ToString
Context.Elements.Add(New EncryptedData(yourEncryptionToken, "#" & a.Signature.Id))
And the wonderful result that comes out from the oven: (geez...I need a life )
<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>
<xenc:DataReference URI="#EncryptedContent-0e6936bf-67a5-48a5-ba8a-d9ba6141e75f" />
<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" />
<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" />
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_
Because of the mutability of some SOAP headers, producers SHOULD NOT use the Enveloped Signature Transform defined in XML Signature. Instead, messages SHOULD explicitly include the elements to be signed. Similarly, producers SHOULD NOT use the Enveloping Signature defined in XML Signature [XMLSIG]
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.
Thursday, December 09, 2004
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...
- Minimum password length
- Implementation of alphanumeric and other different characters and symbols in password
- Password change frequency (in months instead of years )
- Elimination of Weak Passwords such as using names and such
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.
[Author note] I believe WSE 2.0 SP2 has taken some lengths to make sure that Usernametokens which transmits a clear text password are now encrypted.
- 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.
Saturday, December 04, 2004
Thursday, December 02, 2004
I have done quite a few presentations and demos this year. The most fun was the one in MS TechED Asia 2004 in Malaysia where I did 2 sessions on Web Services Enhancements (WSE) 2.0 and 1 on UDDI where I met so many cool people.
I will close out my presentations of the year 2004 with a presentation on MSDN Technology Day here in Singapore (Dec 15 2004) on a topic which I have been doing some research and work on.
- Category: Architecture
- Topic: Moving towards Service-Orientation: What is it actually and is it right for you ?
- Short Synopsis:
I will attempt to explain the facts behind all the maketing hype behind Service-Orientation and why is it so focused on standards and interoperability. Get a better and clearer picture of one of the hottest buzzwords of IT today as I debunk the myths associated with SO(A) today. I will also explain on the guiding principles of Service-Orientation and the impending steps you need to take to embrace this architectural and idea philosophy in moving forward.
Register yourself here.
Wednesday, December 01, 2004
I will be presenting on Web Services Roadmap in Microsoft's Architect Forum on the 3rd Dec 2004 Friday (yes, short notice...Thanks Microsoft Singapore ).
The topic of the forum is ".NET Architecture for Enterprise Agility". This forum is divided into 2 tracks namely ".NET Enterprise Architecture" and the "Service-Oriented Architecture".
I will also meet up with Enterprise Customers who are considering more extensive use of Web Services and who are interested in finding out more as well as to understand what is in the pipeline from Microsoft for Advanced Web Services, its plans and progress.
I hope to be able to answer questions from the architects from the enterprise organizations on the suitability of this growing standard for each specific scenarios.
If I have the time, I would really hope to be able to touch on the offerings of Indigo as well to the audience.
I have heard some presentations from MSFTies and blogs that followed that quotes Lincoln as saying “I didnt have time to write you a short letter so I wrote you this long one instead”
It seems that the people who are re-presenting those topics are using the same quotes again and again.
Lets get the facts straight: It was Mark Twain (1835 - 1910), US humorist, novelist, short story author, & wit who said that and NOT Lincoln.