|
|
This section describes techniques for using X.509 client certificates for Web service authentication.
You can use client certificate authentication within a Web service to authenticate:
Other Web services.
Applications that communicate directly with the Web service (for example, server-based or client-side desktop applications).
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.
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.
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).
| Note |
In scenarios such as these, a local certificate server (accessible only by the two servers) can be used to manage all the Web application certificates. |
In this scenario:
The Web application authenticates its users by using client certificates.
The Web application acts as a gatekeeper and authorizes its users and controls access to the Web service.
The Web application calls the Web service and passes a different certificate that represents the application (or possibly a range of certificates based on the role membership of the caller).
The Web service authenticates the Web application and it trusts the application to perform the necessary client authorization.
IPSec is used between the Web application server and Web service server to provide additional access control. Unauthorized access attempts from other computers are prevented by IPSec. Certificate authentication at the Web service server also prevents unauthorized access.
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.
The following summarizes the sequence of events illustrated by Figure 10.9:
The original caller is authenticated by the Web application using client certificates.
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).
The Web application calls a serviced component running in an out-of-process Enterprise Services application.
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.
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.
An additional process is required (rather than using the Aspnet_wp.exe Web process to contact the Web service) due to the fact that a user profile containing a certificate store is required.
A Web application that runs using the ASPNET account does not have access to any certificates on the Web server. This is because certificate stores are maintained within user profiles associated with interactive user accounts. User profiles are only created for interactive accounts when you physically log on using the account. The ASPNET account is not intended to be an interactive user account and is configured with the “Deny interactive logon” privilege for added security.
| Important: |
Do not reconfigure the ASPNET account to remove this privilege and turn the account into an interactive logon account. Use a separate process with a configured service account to access certificates, as described earlier in this chapter. |
For more information about how to implement this approach, see “ How To: Call a Web Service Using Client Certificates from ASPNET” in the Reference section of this book.
For more information about configuring IPSec, see “ How To: Use IPSec to Provide Secure Communication between Two Servers” in the Reference section of this book.
|
|
