| Because they are applications layered on top of ASP.NET, Web services offer you many opportunities for configuring and implementing security. You can choose to secure things at the level of IIS itself, in the ASP.NET layer, or in the application itself. Depending on the choices you make, nearly any type of security can be applied to a Web service. Platform and Application Security Because SOAP messages come in via HTTP on port 80, IIS handles them on Windows servers. This means that you can use the full spectrum of IIS authentication modes for a Web service: Anonymous, Basic, Digest, Integrated (Windows), and so on. You can also configure IIS to accept requests from only a specified range of IP addresses. If the incoming SOAP request fails to authenticate (assuming that you have disabled Anonymous authentication) or the IP address is not allowed access to the server, that's it; the Web service will not be called.  | Forms authentication and Passport authentication are not supported for Web services applications. |
Assuming that the SOAP request properly authenticates, the next question is which identity will be passed to ASP.NET and then to the Web service. This depends on the type of authentication you've performed and on whether impersonation is enabled. You can use the web.config file to control impersonation for a Web service as shown in the following list: If impersonation is disabled, requests will run in the security context of either the ASPNET account or the SYSTEM account, depending on the <processModel> element setting in the machine.config file. If impersonation is enabled and you allow anonymous access in IIS, requests will run in the security context of the IUSR_ComputerName account. If impersonation is enabled, you do not allow anonymous access, and you do not specify a user identity in the identity tag, requests run in the security context of the Authenticated Windows user. If impersonation is enabled, you do not allow anonymous access, and you do specify a user identity in the identity tag, requests run in the security context of the specified Windows user.
After the user has been authenticated and the identity for ASP.NET requests has been determined, the next line of defense is the ASMX file that implements the Web service itself. You can protect this file with either URL authorization or file authorization. URL authorization is specified within the web.config file as part of the <authorization> element. You saw an example of this earlier in the chapter: <authorization> <deny users = "?" /> </authorization> URL authorization enables you to deny access to a resource (in this case, any resource in the Web service application) to unauthenticated users or to grant access to only specified users. If you're using Windows authentication in IIS, you can also protect the file by using file authorization. For file authorization, right-click on the ASMX file in Windows Explorer and select Properties. The Security tab of the Properties dialog box lets you control which Windows users can read, execute, or modify the file. Figure 12.1. You can set file authorization properties for a Web service via its Properties dialog box. 
Assuming that the authenticated user can read the ASMX file, the final line of defense is code within the file. You can use imperative or declarative code access security or role-based security within an ASMX file, just as you can inside of any other assembly. Configuring Web Services for Security Here are some guidelines for securing your Web services: If you need to be able to authorize access to resources based on the caller's identity, you should set up your server to perform Windows authentication with impersonation. For example, if only some of the authorized users need to read data from a particular database table or access a particular COM+ serviced component, you need to take this approach so that the caller's security context is available to other components. If all users of your Web service need to access the same resources after they're authenticated, you should set up your server to perform Windows authentication without impersonation. Then you can use declarative or imperative security to provide resource access to the account under which ASP.NET is running. You should generally avoid using Windows authentication with a fixed identity (established by the <identity> element in the web.config file). This strategy requires storing the password for the fixed identity account in clear text in the configuration file, which is an inherently insecure situation. On production servers, you should disable HTTP-GET and HTTP-POST access to Web services, limiting them to SOAP access. This is most important when the Web service needs to be available only to clients on your intranet, and those same clients are allowed to browse to the Internet. Under those circumstances, a malicious Web page on the Internet could contain a carefully crafted link that would cause the client to invoke the internal-only Web service. This is possible only through the HTTP-GET and HTTP-POST protocols because Web pages can't create a SOAP message as part of a link. To disable such access, modify the <webServices> section of the machine.config or web.config files, and comment out the HttpPost and HttpGet elements as follows: <webServices> <protocols> <add name="HttpSoap"/> <!-- <add name="HttpPost"/> --> <!-- <add name="HttpGet"/> --> <add name="Documentation"/> </protocols> </webServices>
Remember, the chief challenge in Web services security is to decide how to authenticate users. After a user has been authenticated, a Web service is a Windows application like any other, and you can use the same declarative and imperative security tools that you use with other applications. You can alter the proxy class in a Web service client project to pass the current user's credentials to a Web service, as shown here: public Strings(): base() { base.PreAuthenticate = true; base.Credentials = System.Net.CredentialCache.DefaultCredentials; this.Url = "http://localhost/StringProc/Strings.asmx"; } The proxy classes are based on the System.Web.Services.Protocols.SoapHttpClientProtocol class. You can use the Credentials property to specify the security credentials that the proxy will use to contact the Web services server. You can also use this property to pass the credentials of a specific user in a specific domain, provided that you know that user's password: base.Credentials = _new NetworkCredential("user", "pwd", "domain"); The PreAuthenticate property, when set to true, passes the credentials with the initial SOAP request. If it's set to false, the client sends the credentials only if it receives a "401 Access Denied" response from the server, which results in an extra round-trip across the network. |
