|
|
This chapter describes how to develop and apply authentication, authorization, and secure communication techniques to secure ASP.NET Web services and Web service messages. It describes security from the Web service perspective and shows you how to authenticate and authorize callers and how to flow security context through a Web service. It also explains, from a client-side perspective, how to call Web services with credentials and certificates to support server-side authentication.
Web service security can be applied at three levels:
Platform/transport level (point-to-point) security
Application level (custom) security
Message level (end-to-end) security
Each approach has different strengths and weaknesses, and these are elaborated upon below. The choice of approach is largely dependent upon the characteristics of the architecture and platforms involved in the message exchange.
| Note |
Note that this chapter focuses on platform and application level security. Message level security is addressed by the Global XML Web Services Architecture (GXA) initiative and specifically the WS-Security specification. At the time of writing, Microsoft has just released a technology preview version of the Web Services Development Kit. This allows you to develop message level security solutions that conform to the WS-Security specification. For more information, see http://msdn.microsoft.com/webservices/building/wsdk/. |
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.
When you use platform security, which assumes a tightly-coupled Microsoft® Windows® operating system environment, for example, on corporate intranets:
The Web server (IIS) provides Basic, Digest, Integrated, and Certificate authentication.
The ASP.NET Web service inherits some of the ASP.NET authentication and authorization features.
SSL and/or IPSec may be used to provide message integrity and confidentiality.
The transport level security model is simple, well understood, and adequate for many (primarily intranet-based) scenarios, in which the transport mechanisms and endpoint configuration can be tightly controlled.
The main issues with transport level security are:
Security becomes tightly coupled to, and dependant upon, the underlying platform, transport mechanism, and security service provider (NTLM, Kerberos, and so on).
Security is applied on a point to point basis, with no provision for multiple hops and routing through intermediate application nodes.
With this approach, the application takes over security and uses custom security features. For example:
An application can use a custom SOAP header to pass user credentials to authenticate the user with each Web service request. A common approach is to pass a ticket (or user name or license) in the SOAP header.
The application has the flexibility to generate its own IPrincipal object that contains roles. This might be a custom class or the GenericPrincipal class provided by the .NET Framework.
The application can selectively encrypt what it needs to, although this requires secure key storage and developers must have knowledge of the relevant cryptography APIs.
An alternative technique is to use SSL to provide confidentiality and integrity and combine it with custom SOAP headers to perform authentication.
Use this approach when:
You want to take advantage of an existing database schema of users and roles that is used within an existing application.
You want to encrypt parts of a message, rather than the entire data stream.
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.
WS-Security specifications describe enhancements to SOAP messaging that provide message integrity, message confidentiality, and single message authentication.
Authentication is provided by security tokens, which flow in SOAP headers. No specific type of token is required by WS-Security. The security tokens may include Kerberos tickets, X.509 certificates, or a custom binary token.
Secure communication is provided by digital signatures to ensure message integrity and XML encryption for message confidentiality.
WS-Security can be used to construct a framework for exchanging secure messages in a heterogeneous Web services environment. It is ideally suited to heterogeneous environments and scenarios where you are not in direct control of the configuration of both endpoints and intermediate application nodes.
Message level security:
Can be independent from the underlying transport.
Enables a heterogeneous security architecture.
Provides end-to-end security and accommodates message routing through intermediate application nodes.
Supports multiple encryption technologies.
Supports non-repudiation.
The Web Services Development Kit provides the necessary APIs to manage security in addition to other services such as routing and message-level referrals. This toolkit conforms to the latest Web service standards such as WS-Security and as a result enables interoperability with other vendors who follow the same specifications.
For the latest news about the Web Services Development Kit and WS-Security specifications, see the XML Developer Center page on MSDN at http://msdn.microsoft.com/webservices/.
For more information about the WS-Specification, see the WS-Security Specification Index Page at http://msdn.microsoft.com/webservices/default.asp?pull=/library/en-us/dnglobspec/html/wssecurspecindex.asp .
For more information about GXA, see the article “Understanding GXA” on MSDN.
For discussions on this topic, refer to the GXA Interoperability Newsgroup on MSDN.
|
|
