The transport channel between two endpoints (Web service client and Web service) can be used to provide point-to-point security. This is illustrated in Figure 10.1.

Figure 10.1. Platform/transport level security

When you use platform security, which assumes a tightly-coupled Microsoft® Windows® operating system environment, for example, on corporate intranets:

With this approach, the application takes over security and uses custom security features. For example:

This represents the most flexible and powerful approach and is the one used by the GXA initiative, specifically within the WS-Security specification. Message level security is illustrated in Figure 10.2.

Figure 10.2. Message level security

WS-Security specifications describe enhancements to SOAP messaging that provide message integrity, message confidentiality, and single message authentication.

The gatekeepers within an ASP.NET Web service are:

The following configuration elements show you how to enable Windows (IIS) authentication and impersonation declaratively in Web.config or Machine.config.

<authentication mode="Windows" />
<identity impersonate="true" />

With this configuration, your Web service code impersonates the IIS-authenticated caller. To impersonate the original caller, you must turn off anonymous access in IIS. With anonymous access, the Web service code impersonates the anonymous Internet user account (which by default is IUSR_MACHINE).

The following configuration elements show how you enable Windows (IIS) authentication with no impersonation declaratively in Web.config.

<authentication mode="Windows" />
<!-- The following setting is equivalent to having no identity element -->
<identity impersonate="false" />

The <identity> element within Web.config supports optional user name and password attributes which allows you to configure a specific fixed identity for your Web service to impersonate. This is shown in the following configuration file fragment.

<identity impersonate="true"
          userName="registry:HKLMSOFTWAREYourSecureApp
                    identityASPNET_SETREG,userName"
          password="registry:HKLMSOFTWAREYourSecureApp
                    identityASPNET_SETREG,password" />

This example shows the <identity> element where the credentials are encrypted in the registry using the aspnet_setreg.exe utility. The clear text userName and password attribute values have been replaced with pointers to the secured registry key and named values that contain the encrypted credentials. For details about this utility and to download it, see article Q329290, "HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" in the Microsoft Knowledge Base.

For detailed information about how to configure IIS security settings, see "Configuring Security" in Chapter 8, because the information is also applicable to ASP.NET Web services.

Application level configuration settings are maintained in Web.config files, which are located in your Web service’s virtual root directory. Configure the following settings:

You should use the same techniques to secure Web resources as presented in Chapter 8. In addition, however, for Web services consider removing the HTTP-GET and HTTP-POST protocol from Machine.config on production servers.

By default, clients can communicate with ASP.NET Web services, using three protocols: HTTP-GET, HTTP-POST, and SOAP over HTTP. You should disable support for both the HTTP-GET and HTTP-POST protocols at the machine level on production machines that do not require them. This is to avoid a potential security breach that could allow a malicious Web page to access an internal Web service running behind a firewall.

▸ To disable the HTTP-GET and HTTP-POST protocols for an entire computer

Use a combination of SSL and IPSec to secure communication links.

If you are using Windows authentication, you must specify the credentials to be used for authentication using the Credentials property of the Web service proxy. If you do not explicitly set this property, the Web service is called without any credentials. If Windows authentication is required, this will result in an HTTP status 401, access denied response.

proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;

CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url), // Web service URL
           "Negotiate",        // Kerberos or NTLM
           new NetworkCredential("username", "password", "domainname") );
proxy.Credentials = cache;

proxy.Credentials = new
                      NetworkCredential("username", "password", "domainname");

private void ConfigureProxy( WebClientProtocol proxy,
                             string domain, string username,
                             string password )
{
  // To improve performance, force pre-authentication
  proxy.PreAuthenticate = true;
  // Set the credentials
  CredentialCache cache = new CredentialCache();
  cache.Add( new Uri(proxy.Url),
             "Negotiate",
             new NetworkCredential(username, password, domain) );
  proxy.Credentials = cache;
  proxy.ConnectionGroupName = username;
}

There are a number of authentication approaches that work for cross-browser scenarios. These include:

Proxy server authentication is not supported by the Visual Studio .NET Add Web Reference dialog box (although it will be supported with the next version of Visual Studio .NET). As a result you might receive an HTTP status 407: "Proxy Authentication Required" response when you attempt to add a Web reference.

To work around this issue, you can use the Wsdl.exe command line utility (instead of the Add Web Reference dialog) as shown below.

wsdl.exe /proxy:http://<YourProxy> /pu:<YourName> /pp:<YourPassword> /
pd:<YourDomain> http://www.YouWebServer.com/YourWebService/YourService.asmx

If you need to programmatically set the proxy server authentication information, use the following code.

YourWebServiceProxy.Proxy.Credentials = CredentialsCache.DefaultCredentials;

To use Kerberos delegation, all computers (servers and clients) must be running Windows 2000 or later. Additionally, client accounts that are to be delegated must be stored in Active Directory and must not be marked as "Sensitive and cannot be delegated."

The following tables show the configuration steps required on the Web server, and application server.

<authentication mode="Windows" />

<identity impersonate="true" />

<authentication mode="Windows" />

<identity impersonate="true" />

As an alternative to Kerberos delegation, you can use Basic or Forms authentication at the Web application to capture the client’s credentials and then use Basic (or Integrated Windows) authentication to the Web service.

With this approach, the client’s clear text credentials are available to the Web application. These can be passed to the Web service through the Web service proxy. For this, you must write code in the Web application to retrieve the client’s credentials and configure the proxy.

// Retrieve client's credentials (available with Basic authentication)
string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
// Associate the credentials with the Web service proxy
// To improve performance, force preauthentication
proxy.PreAuthenticate = true;
// Set the credentials
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url),
           "Basic",
           new NetworkCredential(uid, pwd, domain) );
proxy.Credentials = cache;

// Retrieve client's credentials from the logon form
string pwd = txtPassword.Text;
string uid = txtUid.Text;
// Associate the credentials with the Web service proxy
// To improve performance, force preauthentication
proxy.PreAuthenticate = true;
// Set the credentials
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url),
           "Basic",
           new NetworkCredential(uid, pwd, domain) );
proxy.Credentials = cache;

<authentication mode="Windows" />

<authentication mode="Forms" />

<identity impersonate="false" />

<authentication mode="Windows" />

<identity impersonate="true" />

If you use the trusted subsystem model, you may still need to flow the original caller’s identity (name, not security context), for example, for auditing purposes at the database.

You can flow the identity at the application level by using method and stored procedure parameters and trusted query parameters (as shown in the following example) can be used to retrieve user-specific data from the database.

SELECT x,y,z FROM SomeTable WHERE UserName = "Alice"

The following tables show the configuration steps required on the Web server, and application server.

<authentication mode="Windows|Forms|Passport" />

<identity impersonate="false" />

proxy.Credentials = DefaultCredentials;

<authentication mode="Windows" />

<identity impersonate="false" />

A Web service cannot use client certificates to authenticate callers if they interact with an intermediate Web application, because it is not possible to forward the original caller’s certificate through the Web application and onto the Web service. While the Web application can authenticate its clients with certificates, the same certificates cannot then be used by the Web service for authentication.

The reason that this server-to-server scenario fails is that the Web application does not have access to the client’s certificate (specifically its private key) in its certificate store. This problem is illustrated in Figure 10.7.

Figure 10.7. Web service client certificate authentication

To address this restriction, and to support certificate authentication at the Web service, you must use a trusted-subsystem model. With this approach, the Web service authenticates the Web application using the Web application’s certificate (and not the original caller’s certificate). The Web service must trust the Web application to authenticate its users and to perform the necessary authorization to ensure that only authorized callers are able to access the data and functionality exposed by the Web service.

This approach is shown in Figure 10.8.

Figure 10.8. The Web service authenticates the trusted Web application

If the authorization logic within the Web service requires multiple roles, the Web application can send different certificates based upon the role membership of the caller. For example, one certificate may be used for members of an Administrators group (who are allowed to update data within a back-end database) and another certificate may be used for all other users (who are authorized only for read operations).

In this scenario:

Solution Implementation

To use certificate authentication at the Web service in this scenario, use a separate process to call the Web service and pass the certificate. You cannot manipulate the certificates directly from the ASP.NET Web application because it does not have a loaded user profile and associated certificate store. The separate process must be configured to run using an account that has an associated user profile (and certificate store). You have two main options:

• You can use an Enterprise Services server application

• You can use a Windows service.

Figure 10.9 illustrates this scenario with an Enterprise Services server application.

Figure 10.9. Client certificate authentication with Web services

The following summarizes the sequence of events illustrated by Figure 10.9:

1. The original caller is authenticated by the Web application using client certificates.

2. The Web application is the gatekeeper and is responsible for authorizing access to specific areas of functionality (including those that involve interaction with the Web service).

3. The Web application calls a serviced component running in an out-of-process Enterprise Services application.

4. The account used to run the Enterprise Services application has an associated user profile. The component accesses a client certificate from its certificate store, which is used by the Web service to authenticate the Web application.

5. The serviced component calls the Web service, passing the client certificate on each method request. The Web service authenticates the Web application using this certificate and trusts the Web application to correctly authorize original callers.

Transport level options include:

These options may be appropriate if the following conditions are met:

Message level approaches can be used to guarantee the confidentiality and integrity of messages as they pass through an arbitrary number of intermediate systems. Messages can be signed to provide integrity. For confidentiality, you can choose between encrypting the entire message or part of a message.

Use a message level approach if the following conditions are met: