|
|
This chapter has focused on platform/transport level (point-to-point) Web service security provided by the underlying services of ASP.NET, IIS, and the operating system. While platform level security provides secure solutions for tightly-coupled intranet scenarios, it is not suited to heterogeneous scenarios. For this, message level security provided by the GXA WS-Security specification is required. Use the Web Services Development Kit to build message level Web service security solutions.
For tightly-coupled Windows domain environments:
If you want to flow the original caller’s identity from an ASP.NET Web application to a remote Web service, the ASP.NET Web application should use Kerberos authentication (with accounts configured for delegation), Basic authentication, or Forms authentication.
With Kerberos authentication, enable impersonation with the Web application and configure the Credentials property of the Web service proxy using DefaultCredentials.
With Basic or Forms authentication, capture the caller’s credentials and set the Credentials property of the Web service proxy by adding a new CredentialCache object.
For Web-service to Web-service scenarios:
Use Basic or Kerberos authentication and set credentials in the client proxy.
Use an out of process Enterprise Services application or a Windows service to manipulate X.509 certificates from Web applications.
As far as possible, use system level authorization checks such as File and URL authorization.
For granular authorization (for example, at the Web method level) use .NET roles (declaratively and imperatively).
Authorize non-Windows users by using .NET roles (based on a GenericPrincipal object that contains roles).
Disable HTTP-GET and HTTP-POST protocols on product servers.
Use transport level security if you are not worried about passing messages securely through intermediary systems.
Use transport level security if SSL performance is acceptable.
Use WS-Security and the Web Services Development Kit to develop message-level solutions.
|
|