Editor's Note: This is the fourth and final excerpt from O'Reilly's .NET Framework Essentials, 2nd Ed. by Thuan L. Thai and Hoang Lam. The complete series of excerpts covers Web services in the context of the .NET framework. Part 1 was an overview of .NET Web services. Part 2 focused on Web service providers. Part 3 covered Web services consumers. This fourth part covers Web services and security.
This section demonstrates how to incorporate security into your Web Service. We will do so in two ways: system security and application security. System-level security allows for restricting access to the Web Services from unauthorized clients. It is done in a declarative fashion, whereas application-level security is more flexible. With system-level security, you will most likely have the list of authorized clients' IP addresses that you will let access your Web Service through the use of some configuration-management tools. With application-level security, you will incorporate the authentication into your Web Service, thus providing a more flexible configuration.
Because Web Services communication is done through HTTP, you can apply system-level security on Web Services just as you do for other web pages or resources on your web site.
There are a number of different ways you can secure your Web Services. For a B2B solution, you can use the IIS Administration Tool to restrict or grant permission to a set of IP addresses, using the Internet Protocol Security (IPSec) to make sure that the IP address in the TCP/IP header is authenticated. When you rely only on the client to provide the IP in the TCP/IP header, hackers can still impersonate other host IPs when accessing your Web Services. IPSec authenticates the host addresses using the Kerberos authentication protocol. You can also use a firewall to restrict access to your Web Services for your partner companies. For a business-to-consumer (B2C) scenario, you can take advantage of the authentication features of the HTTP protocol.
|
Related Reading 
.NET Framework Essentials |
To show how to use the authentication feature of the HTTP protocol to secure your Web Services, let's revisit the example Web Service we have in this chapter, PubsWS. All we have to do to secure PubsWS Web Service is go to the IIS Admin Tool and choose to edit the File Security properties for the PubsWS.asmx. Instead of keeping the default setting, which leaves this file accessible to all anonymous users, we change this setting to "Basic Authentication" only, which means unchecking "Anonymous Access" and checking only "Basic Authentication" in the Authenticated Access frame. After this change, only users that pass the authentication can make use of the Web Service.
For real-life situations, of course, we are not going to use just the Basic Authentication method, because it sends the username and password in clear text through the HTTP channel. We would choose other methods, such as Secure Sockets Layer (SSL) underneath Basic Authentication, so that the data passed back and forth is secure. Available methods include:
A less systematic way of securing your Web Services involves taking security into your own hands. You can program your Web Services so that all of their methods require an access token, which can be obtained from the Web Service after sending in the client's username and password. The client credentials can be sent to the server through SSL, which eliminates the risk of sending clear-text passwords across the wire. Through this SSL channel, the server returns an access token to the caller, who can use it to invoke all other Web Service methods. Of course, all of the other web methods that you publish have to have one parameter as the token. A simple pseudocode example of a bank account Web Service can be as follows:
Web Service Bank Account
Web Methods:
Login(user id, password) returns access token or nothing
Deposit(access token, account number, amount, balance) returns boolean
Withdraw(access token, account number, amount, balance) returns boolean
The only method that should be on SSL is the Login method. Once the token is obtained, it can be used for other web methods. Of course, you should be able to make sure that subsequent calls using this token are coming from the same IP as the Login( ) call. You can also incorporate an expiration timestamp on this access token to ensure that the token only exists in a certain time frame until a renewal of the access token is needed.
The Microsoft .NET Cryptographic Services can be very useful if you choose this route. DES, RC2, TripleDES, and RSA encryption/decryption algorithms are supported along with hashing methods such as SHA and MD5. These implementations in the .NET library enable developers to avoid low-level grunt work and focus on the application logic.
In this chapter, we've introduced you to the new paradigm of applications--the enterprise application. You are no longer restricted to homogeneous platforms for implementing your solutions. With Microsoft Web Services, your solutions can span many different platforms because the communication between Web Services is done through standard Internet protocols such as HTTP and XML. The distributed components in Windows DNA with which you may be familiar are now replaced by Web Services. Using Web Services as components in a distributed environment allows for a heterogeneous system. The Web Services in your system can not only be implemeneted in different languages, but they can even be on different platforms. Because of this greater interoperability, Web Services are eminently suitable for business-to-business (B2B) integration.
View catalog information for .NET Framework Essentials, 2nd Ed.
Return to the .NET DevCenter.
Copyright © 2009 O'Reilly Media, Inc.