Working Together Securely: Developer Notes
As Matt talks about here, we did a pretty good presentation last week at the 2004 Nebraska CERT coference. Matt's deck is here, mine is here. We talked about an system we built to demonstrate secure communications between open source platforms and Microsoft.NET about some of the lessons we learned. I wanted to quickly share some bits and some lessons learned.
Our goal was to create a system that mimics a real-world Service Orienteed Application. Matt's bits were build on the combination of Apache, Tomcat and Axis, while I used IIS6 and ASP.NET. For the most part, writing the code was the easiest part! The hardest part, at least on my side, was trying to get .NET to work with a self-signed certificates.
Once we were able to start flinging SOAP packages at each other, we decided to step our security a bit by first requiring basic security. Now if there is a trick to this from a Web Services stand point, and I'm not saying that there is, but if there is, it's using the PreAuthenticate method. In code, that looks like this:
whProxy.Credentials = New Net.NetworkCredential(enc.SimpleDecrypt(ConfigurationSettings.AppSettings("uid")),
enc.SimpleDecrypt(ConfigurationSettings.AppSettings("pwd")))
whProxy.PreAuthenticate = True
Setting this property to true causes the proxy class to transmit the basic authentication headers with the initial request. As you may be familar with in IE, requests are normally made first without any authentication data. The remote Web server then normally sends back a 401 status code, then the proxy has to marshal up another request with the credentials. Using the PreAuthenticate header cuts out that first useless round-trip.
Now, you might be wondering what the heck "enc" is and what the SimpleDecrypt method does. "Enc" is simple VB.NET class that uses GUIDs and the RijndaelManaged cryptography provider to encyrpt and decrypt string value. I like this approach because it doesn't require the programmer or the the administrators know any of the keys. At the same time, its not the strongest of approaches since, at least currently, you can use the same class instance to encrypt or decrypt a value without having to provide any other keys. It's probably most suitable only in cases where you need to keep data protected from non-developers and you can use a strongly named key for all of the assemblies involved. If you're interested in seeing the source code, please contact me off-line.
Once we had Basic Authentication working, our next goal was to get SSL going. That proved to be easier said than done. Installing an SSL Certificate isn't hard at all, especially if you use the SelfSSL tool from the IIS6 Resource Kit. What is troublesome is getting .NET to work with self-signed certificates. Since these certificates are generally considered "untrustworthy," by policy the .NET runtime will reject them. There's more discussion of this topic here: The King of Pain: Secured Asynchronous Web Services
We finally did get much working reliably, at least basic authentication over SSL. For me, though, the most important lesson learned was "we really, really would need WS-I (and the WSE) if we were doing this for real." Why do I say that? Consider:
- In our example, we relied almost entirely on transport level security, but the big goal for SOAP is to be transport independent. It's really only by taking advantage of SOAP's ability to have custom headers and attachments that you get around this in a secured channel environment. The message needs to contain both the payload and the security metadata to be free of any transport specific bindings.
- It's pretty easy to make SOAP go from point A to point B, but its not so easy to make the messages go from point A to C through B, particuarly in a secured manner. What you need is some way for "B" to see the routing information on message so it can know what point "C" is, but you'll also want to protect the message payload from snooping or modification by "B." Several key parts of the WS-I specification suite are helpful here: Routing and SecureMessaging.
Frankly, this is why I'm pretty excited about Indigo now. While the WSEs are a big help, they are a complete solution, especially when Federated Identity gets involved. But that's the needed technology, IMHO, to make to big fractal tangle of trust work.