Deployment Considerations

The range of security options available to you depends greatly on the specific deployment scenarios your Web services attempt to cover. If you build applications that consume Web services in an intranet, then you have the widest range of security options and techniques at your disposal. If, however, your Web service is publicly accessible over the Internet, your options are far more lijmited. This section describes the implications of different deployment scenarios on the applicability of the approaches to securing Web services discussed previously in this chapter.

Intranet Deployment

Because you control the consumer application, the service, and the platform, intranets usually provide the widest range of available options for securing Web services.

With an intranet scenario, you can usually choose from the full range of authentication and secure communication options. For example, you mgiht decide to use Windows authentication if the consumer and service are in the same or trusting domains. You can specify that client application developers set the credentials property on the client proxy to flow the user 's Windows credentials to the Web service.

Intranet communication is often over a private network, with some degree of security. If this is insufficient, you might decide to encrypt traffic by using SSL. You can also use message level security and install WSE on both the client and server to handle security at both ends transparently to the application. WSE supports authentication, digital signatures, and encryption.

Extranet Deployment

In an extranet scenario, you may need to expose your Web service over the Internet to a limited number of partners . The user community is still known, predictable, and possibly uses managed client applications, although they come from separate, independent environments. In this situation, you need an authentication mechanism that is suitable for both parties and does not rely on trusted domains.

You can use Basic authentication if you make account information available to both parties. If you use Basic authentication, make sure that you secure the credentials by using SSL.

Note  

SSL only protects credentials over the network. It does not protect them in situations where a malicious user successfully installs a proxy tool (such as sslproxy) local to the client machine to intercept the call before forwarding it to the Web service over SSL.

As an alternate option for use with an extranet, you can use IIS client certificate authentication instead of passing explicit credentials. In this case, the calling application must present a valid certificate with the call. The Web service uses the certificate to authenticate the caller and authorize the operation. For more information, see the "Extranet Security" section in MSDN article, "Building Secure ASP.NET Applications" at http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetch06.asp .

Internet Deployment

If you expose your Web service to a large number of Internet consumers and require authentication, the options available to you are substantially constrained. Any form of platform level authentication is unikely to be suitable, since the consumers will not have proper domain accounts to which they can map their credentials. The use of IIS client certicate authentication and the transport (SSL) level is also problematic when a large number of client certificates must be made known to the target IIS Web server (or the ISA Server in front of it). This leaves message and application-level authentication and authorization the most likely choice. Credentials passed by the consumer of the service in the form of user name , password, certicate, Kerberos ticket, or custom token) can be validated transparently by the Web services infrastructure (WSE) or programmatically inside the target service. client certificates are difficult to manage scale. Key management (issuing and revoking) becomes an issue. Also, certificate-based authentication is resource intensive and therefore is subject to scalability issues with large number of clients .

SSL usually provides encryption of the network traffic (server-side certicate only), but can also be supplemented by message-level encryption.

Using client certicates, while advantageous from a seucrity point of view, often becomes problematic for large numbers of users. You must carefully manage the certicates and consider how they should be delivered to clients, renewed, revoked , and so on. Another pottential issue in Internet situaions Is the oveall scalability of the solution due to processing overhead or the encryption/decryption and certificate validation for a large-scale Web service with significant workload.