Sample Chapter: Early Adopter Hailstorm (.NET My Services)
Microsoft's .NET My Services is a family of XML web services that improves operational functionality of .NET applications and web pages. In this article Tim takes a look at a sample chapter from Wrox's "Early Adopter Hailstorm (.NET My Services)" book. The chapter talks about what exactly .NET My Services are and how they are composed amongst other things.
Sample Chapter: Early Adopter Hailstorm (.NET My Services) - Making Conversation (Page 2 of 10 )
When HailStorm is finally released in the first half of 2002 it will sit behind the identity/security mechanism offered by Passport v3.0, which is due be released some time earlier. At the time of writing, Passport v2.0 had just been released and there were no more specifics on v3.0 beyond the knowledge that it will stop using its current proprietary authentication mechanism in favor of the industry standard Kerberos system. This would suggest that Passport might become the authentication mechanism in the next version of the Windows OS family; Kerberos is already the Windows 2000 security mechanism. If this happens, a user logged on to their computer would automatically be logged into all Passport-enabled web sites as well.
As we saw in Chapter 1, HailStorm offers a set of services in the form of a digital safe deposit box for which a user pays a small subscription fee. This sits behind Passport as an additional, decidedly useful feature which clients may make use of if they want. Users log on to a HailStorm endpoint (a web site, XBox game, Stinger smart phone, PocketPC etc.) in the usual way through Passport. If they already have a digital safe deposit box, the endpoint to should give the user the option or alter the information stored within the DSDB. They don?t have a DSDB then they should be given the option to create one.
A Secure Future
So how will an endpoint perform a security handshake with and send a request to the Passport/HailStorm servers once HailStorm v1.0 has arrived? Let's look at the interaction with the Kerberos part of the Passport system first.
1. Once a user has clicked on the Passport login icon, the endpoint sends a request to Passport (which acts as the Key Distribution Center or KDC) for a ticket-granting ticket (TGT) for the user.
2. Passport returns a session key encrypted with the user's secret key and the TGT encrypted with its (Passport's) own secret key. The TGT also contains the session key.
3. The endpoint asks the user for their password and generates their secret key. If the password was correct, the endpoint can now decrypt the session key.
4. The endpoint now asks Passport for a ticket to access the HailStorm servers. Along with the request, it sends the still-encrypted TGT and some information that authenticates the user (UserID, PlatformID, and ApplicationID) encrypted with the session key.
5. Passport decrypts the TGT, retrieves the session key from it, and decrypts the authentication information. All being well, it generates a new session key for the endpoint's talk with HailStorm and incorporates the key and the various IDs into a new ticket. The ticket is then encrypted with a secret key it can share with HailStorm on demand and is sent back to the endpoint along with the new session key again encrypted with the user's secret key.
The endpoint now has the information it needs to talk to HailStorm ? the Kerberos ticket and the session key, which it decrypts with the user's secret key. It can now build a message to HailStorm, authenticate it, and expect a response.
1. The header of the SOAP message holds the address of the server hosting the appropriate web service and the still-encrypted TGT and User PUID for identification.
2. The body of the SOAP message to HailStorm contains an instruction to retrieve or amend information. This and the rest of the body are encrypted with the session key.
3. Once completed, the endpoint sends the message to the named HailStorm server.
4. On receipt of the message, HailStorm sends Passport the PUID and asks for the appropriate secret key to decrypt the ticket, which Passport delivers.
5. HailStorm decrypts the ticket and attempts to decrypt the body of the message with the session key.
6. All being well, the instruction is carried out and either the appropriate results or an error message are returned in the body of the SOAP response message encrypted by the session key.
In overview, it's apparent that only encrypted information is ever sent across the wire to ensure that the request, response, and user information remain as secure as possible.
At this point, it may not be too surprising if you find yourselves questioning the wisdom of Microsoft's choice of Passport as HailStorm's authentication mechanism. It is after all a Windows-only technology in the main. The key thing to remember is that Kerberos is an industry standard and not originally from Redmond. By adopting this, HailStorm can be accessed by any endpoint that can produce the right ticket and session key ? not just Passport. Should other community-based sites like Yahoo or AOL decide to adopt Kerberos as their login mechanism; their users will have access to their own digital safe-deposit boxes as well. Likewise, Passport users will be able to access the facilities available to AOL and Yahoo.