XML Web Service Security

XML Web services have many of the same security considerations as ASP.NET pages. Some XML Web services are public and anonymous, such as an airline schedule browsing program. Others are private, such as a financial company’s mutual fund trading program. Most will require at least some degree of authentication and authorization, more in the case of medical or financial records, less in the case of $20/year magazine subscriptions. There is no One True security design for XML Web services. Even more than for ASP.NET pages, you have to look carefully at the specific details of every case.

Most XML Web services will require some sort of security.

We’ve seen that XML Web services are layered on top of ASP.NET. Since we get services such as state management from the underlying layer, it would only make sense that we would get our security from it as well. While this happens in some situations, it doesn’t always solve our problems. XML Web services differ from Web Forms because the client of an XML Web service may not be a human being; it could easily be another computer program. In ASP.NET forms authentication, we redirected an unauthenticated user to a Web form and required her to type in her authentication credentials. That won’t work for XML Web services, so we have to come up with some automatic way for the user to present authentication credentials. Passport authentication suffers from the same problem; it is likewise human-centric.

XML Web services can’t depend on a human user to enter credentials.

Our XML Web services can get automatic authentication from ASP.NET today if we select Windows authentication. But as I explained in Chapter 3, this approach works well only in Windows-only environments. That’s fine for a corporate intranet, where you have control over all the software and machines. Security-conscious designers can do things such as restrict the IP addresses from which clients are allowed to access the service, require the clients to present X509 certificates issued by their own certificate authority or by a third party, or install encrypted network cards in all their computers. But to my mind, that’s exactly what XML Web services are not about. The whole point of XML Web services is to be open to everyone on the amorphous Internet, from anybody, to anybody. We need a security mechanism that works no matter what hardware and software environments the clients are using. We don’t currently have a point-and-click mechanism in .NET, but as I’ll show you, we can use .NET utility objects to roll our own without too much trouble.

Windows authentication only works well in a Windows-only network, which the Internet is not.

I wrote a sample XML Web service that simulates a magazine publisher that allows paying clients to request the text of articles from its server. Users must purchase a subscription, which is done outside the XML Web service, perhaps on the human-readable Web site with a credit card. The user is then given a user ID and password, which is good for unlimited requests for some period of time.

An Internet XML Web service security example starts here.

The XML Web service has two methods, one called Login and one called RequestArticle. The first takes a user ID and password and returns an admission ticket, a “session key” if you will. The second requires this admission ticket and an article number, and returns the article. Figure 4-16 shows the workflow in this system.

Figure 4-16: XML Web service security example workflow.

I really don’t want anyone to steal a user ID and password. Anyone who did that could use my system for free for the duration of that user’s account. They couldn’t hurt anything with it, as I don’t store any sensitive information about my users, but I don’t want the bad publicity that a theft would bring. So my client would use Secure Sockets Layer (SSL) for making the call to my service’s Login method. That’s easy to do—simply change HTTP to HTTPS in the request URL. This causes the client to request the server’s public key, use that to negotiate a session key, and use the session key to encrypt the call transmitting the user ID and password. That way no one with a packet sniffer can record the user ID and password to break in later. The drawback is that the handshaking and encryption require a significant amount of extra time and CPU cycles. (Note: the sample program supplied with this book uses HTTP instead of HTTPS, because most readers will find it difficult to set up their servers to handle HTTPS.)

The XML Web service accepts a user ID and password over SSL to avoid eavesdropping, and returns an encrypted admission ticket.

The Login method on the server checks to see if the user is in my subscriber database and if the subscription is current. My sample program simulates that with hardwired names. If the user ID or password is not valid, the server throws an exception and it’s up to the client to deal with it. The server then creates an admission ticket, using the forms authentication utility functions that I demonstrated in Chapter 3. The ticket contains the user’s name, the roles to which the user belongs, and an expiration time. I encrypt the ticket using other system utility functions and return it to the client in the form of a string. The client retains this string for use in future calls.

When the client wants to request an article, he calls the GetArticle method, passing the encrypted admission ticket and the desired article number. The server decrypts the admission ticket using the system utility functions. My server now knows who the user is, what roles he belongs to, and whether the ticket’s expiration time has passed. If a client presents an expired ticket in an article request, the server throws an exception and the client has to send the user ID and password again (over SSL). My sample program does this internally without bothering the user.

The client presents the admission ticket over clear HTTP in subsequent service requests.

I didn’t use SSL for requesting an article because I didn’t want to take the performance hit. Anyone who might be sniffing packets could read the clear text of the articles being retrieved, though since the user’s name is encrypted in the ticket, they won’t know who is reading which article. If the data were sensitive in itself, such as medical or financial records, I’d probably use SSL throughout regardless of time cost, but in this case, it’s just an article that the snooper didn’t select. If a snooper records the ticket string and plays it back in a spoof request, he’d be able to request articles without paying for a subscription, but only for the duration of the ticket’s validity, which I set to half an hour when I create it.

I don’t use SSL to prevent eavesdropping on non- login service calls because my data isn’t sensitive and my admission tickets expire frequently.

This security architecture was relatively easy for me to implement. Without spending too much developer time and money, I’ve made the cost of cracking my system significantly higher than the cost of buying a subscription, and limited the damage done in case someone does crack it. If some frustrated geek has nothing better to do on a lonely Saturday night than sniff my packets to hijack free article retrieval for an average time of 15 minutes per break-in, welcome to it, say I.

You have to balance security programming effort and cost against the cost of a security failure.

You can see the design decisions that I’ve made, trading off development time against security against run-time efficiency. I hope you see why I think I have about the right balance for this particular system. Different systems will require different trade-offs. Pick the one that makes you the most money, as I’ve done.

Tips from the Trenches

The new enhancements to Web services offer a lot of security capabilities. Don’t roll any of your own until you’ve had a look at them.