Security Considerations

Team Fly

Page 339

When you press F5 to run the program, you should see an HTML-formatted message, returned from this Web service, appear in your message box. If this example doesn't work for you, try other available Web services until you discover one that does work.

The third oldest profession is security—the attempt to conceal information without actually destroying it in the process, or the attempt to defend yourself without actually imprisoning yourself in the process.

These goals—privacy and protection—have been sought since envy became a factor in human relations. In other words: since Adam's boys. And each time we think we're getting close to an effective solution, the goal recedes and we realize that the envious are just as clever as the envied.

Web services are just as vulnerable to security problems as any other technique that involves Internet messaging. You have the problem that someone might intercept the message and read it. This can be solved pretty effectively with strong encryption, as described in Chapters 5 and 6. Similarly, the related problem of validation (has someone changed $1000 to $100000?) can be solved via encryption. If they cannot read the message, they cannot modify it.

The other security issue, authentication, is less easily solved, especially when you consider that one goal of Web services can be described as letting strangers into your server so they can execute commands and invoke procedures. That's just the sort of thing that virus protection software and firewalls are designed to prevent.

HTTP and HTML are supposed to slide into servers right through port 80. Firewalls permit this because HTTP and HTML transport and express only harmless documents, not executables.

SOAP, though, extends these capabilities beyond page description and text messages into the ability of a remote client to invoke procedures and issue commands on the server.

Some experts suggest blocking text/xml content types, or messages with SOAPAction in their headers, but this throws the babies out with the bathwater. The committees that govern XML and, by extension, Web services have been trying to come up with practical recommendations. Likewise, firewall vendors are also seeing what can be done to tell the bad guys from the good guys. Can the problem of entertaining strangers be solved? Time will tell, but history suggests that the answer is no. Security can often be strengthened, but never perfected.

Summary

This chapter covers Web services and related technologies. You saw that computing—no matter how distributed it becomes, and no matter what names they give new technological twists—always comes down to two things: data and processing. Web services are no different. True, they send messages via XML, they operate remotely, and they face special security and communications challenges. But, in essence, they accept a request to process some data, just like any classic function, utility, or application.

You learned how to write a Web service, how to cache data, and how to consume a Web service. You also saw how to preserve state using the Session object and how to deal with database connections.

The chapter concluded with an examination of WSDL, the Web service description language; XML and SOAP features; and the UDDI registry, the official Universal Description, Discovery, and Integration registry where you can list your Web services, and locate others' services, along with descriptions of how to consume them.

Team Fly