MCAD/MCSD Training Guide (70-310): Developing XML Web Services and Server Components with Visual Basic(R) .NET and the .NET Framework

‚   ‚  

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.

In this section of the chapter, I'll first trace through the layers involved in a Web service, showing you where and how you can apply security. Then I'll give you some general advice on securing Web services. Finally, you'll learn a little about the new WS-Security specification, which will bring additional security tools to Web services.

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.

NOTE

No Forms or Passport 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 make settings in the web.config file for a Web service to control impersonation just as you can for any other ASP.NET application (see the section "Implementing Impersonation" earlier in the chapter for details). In particular,

• If impersonation is disabled, requests will run in the security context of either the ASPNET account or the system account, depending on the processModel 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 will 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 will 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 or file authorization.

URL authorization is specified within the web.config file as part of the <authorization> tag. You saw an example of this earlier in the chapter:

<authorization> <deny users="?" /> </authorization>

URL authorization allows 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, shown in Figure 11.9, lets you control which Windows users can open the file.

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 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 should be able to read access from a particular database table or via a particular COM+ serviced component, you'll need to take this approach so that the caller's security context is available to other components .

• If all users of your Web service should be able to access the same resources once 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.

  WARNING

  Impersonation and Scalability Windows authentication with impersonation can limit the scalability of applications that depend on database connections. That's because connection pooling only happens for connections with identical security contexts. If you use impersonation, connections won't pool between different users. In this situation, you might want to consider Windows authentication without impersonation instead.

• You should generally avoid using Windows authentication with a fixed identity (established by the <identity> element in the web.config file). That's because 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 should be only available 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 only possible 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 file 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. You'll see some sample code for interacting with a secured Web service in Exercise 11.1. Once 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.

WS-Security

The final topic you should be aware of in Web services security is a new standard called WS-Security. You can be relatively certain that this material will not be on the 70-310 exam for the simple reason that it was not formalized until after the exam was written. But it's such a crucial piece of the Web services puzzle that I'd be remiss if not at least mentioning it.

WS-Security is part of a new set of Microsoft standards, GXA, introduced in late 2002. GXA, the Global XML Web Services Architecture, is Microsoft's latest idea about how to make Web Services more reliable and functional. GXA isn't a single protocol; it's a scheme for building a whole family of protocols that can be used in many Web Services applications. Some of the design principles for the GXA protocols include

• XML-based data models ‚ The good news is that you already know XML. The bad news is that you probably don't know about XML Information Sets, otherwise known as Infosets, so there's still something to learn here. http://msdn.microsoft.com/library/en-us/dnxml/html/xmlinfoset.asp will get you started with the basics.

• Transport Neutrality ‚ In theory, at least, GXA does not depend on HTTP. Of course, in theory SOAP doesn't depend on HTTP either.

• Application Domain Neutrality ‚ The GXA protocols are designed to be broadly useful, but extensible for specific application domains. That's good for the developer because it means more general-purpose (and hence saleable) skills.

• Decentralization and Federation ‚ GXA does not depend on central authorities to manage things. You can view this as a good move from the standpoint of scalability. You can also view this as Microsoft trying to avoid extending its "Big Brother" image if you're so inclined.

• Modularity ‚ GXA is designed to be modular, so you only need to learn the pieces that you want to use.

The goal of WS-Security is to add security features directly to the SOAP messages passed to and from a Web service rather than using external services (such as IIS) to manage security. WS-Security does this by defining a set of namespaces and tags that can be used within the SOAP Header to perform three functions:

• Authentication

• Encryption

• Signing

When WS-Security is fully implemented, SOAP messages will be able to contain user credentials and digital signatures to verify those credentials, as well as be encrypted to protect those credentials from eavesdroppers. You can learn more about WS-Security in the GXA section of the MSDN Web site. A good starting point is Scott Seely's white paper "Understanding WS-Security," available at http://msdn.microsoft.com/library/en-us/dnglobspec/html/wssecurspecindex.asp.