영욱닷컴(http://youngwook.com)

What's New and Different in WSE 2.0?

Web Services Enhancements for Microsoft .NET version 2.0 includes a number of enhancements over earlier versions of WSE to more easily apply security policy, establish long-running secure conversations, and work in multiple hosted environments. Some of these enhancements, such as the WSE 2.0 support for the newly-approved Oasis standard version of WS-Security, mean WSE 2.0 cannot exchange SOAP messages with WSE 1.0. The good news is that you can use the WSE 2.0 assemblies in the same applications as your WSE 1.0 assemblies so that a single application can communicate with both WSE 1.0 and WSE 2.0 Web services. An overview of other features and version issues is provided below:

• New and Enhanced Features
• Version Compatibility

New and Enhanced Features

This section describes the new and enhanced features included in the WSE 2.0.

Policy

WSE version 2.0 enables developers to use configuration files to specify requirements for receiving and sending messages. Previously, an application receiving a SOAP message had to contain code to verify message-receiving requirements, such as whether the SOAP message was digitally signed or encrypted. Likewise, the developer of the application sending the SOAP message had to know the receiver's message requirements and add code to the sending application. Now those requirements, known as policy assertions, can be expressed in a configuration file. When policy assertions are configured, WSE runtime checks incoming or outgoing SOAP messages to determine whether they comply with the policy assertions; when they do not, WSE runtime returns a SOAP fault. WSE has a set of predefined policy assertions, such as the requirement that the body of the SOAP message be signed with an X.509 certificate. In addition, the policy system can be extended to include custom policy assertions.

WS-Trust and Security Context Tokens

WSE's support of the WS-Trust and WS-SecureConversation specifications provides the capability to programmatically request a security token using a SOAP message, and that token can be used for a series of SOAP messages between a SOAP message sender and a target Web service. WSE allows you to build a security token service or configure one that issues security context tokens. When configured to issue security context tokens, a SOAP message sender can use the token to sign and/or encrypt a series of SOAP messages, known as a conversation, between a SOAP message sender and the target Web service.

Kerberos Security Tokens

WSE supports the use of security tokens based on Kerberos tickets. Kerberos tickets can be used to digitally sign and encrypt SOAP messages, along with authorizing access to a Web service based on a Kerberos security token.

Role-based Security Using Security Tokens

WSE supports role-based authorization for SOAP messages by constructing a principal from a security token in the SOAP message, such as the one used to digitally sign the SOAP message. Because there may be multiple security tokens in a SOAP message, WSE allows the application to configure which security token is used for authentication and authorization. When this security token is a user name and password or Kerberos ticket, the contents of the security token are used to authenticate against a Windows account. If the credentials are authenticated, a Windows principal is created and assigned to the Principal property of the security token used to sign the SOAP message. Using that Principal property, code in a Web service method can decide whether a given role is authorized to execute all or portions of the Web service method. Alternatively, role-based security can be declaratively set using policy.

Signing and Encrypting Security Tokens

When a security token is added to a SOAP message, it is added to the SOAP message in the form of an XML element in the WS-Security SOAP header. That XML element can now be digitally signed or encrypted. This can be very useful when the security token is a UsernameToken, which is based upon a user name and password — especially if the password is sent in plaintext. And when you use role-based security with a UsernameToken, the password must be sent in plaintext. Therefore, encrypting the UsernameToken containing a plaintext password can make it more difficult for an intermediary to steal a user's password.

SOAP Messaging

With SOAP messaging, WSE supports a flexible and lightweight mechanism for sending and receiving SOAP messages. This mechanism allows applications to switch between the TCP and HTTP transport protocols relatively easily. When the TCP transport protocol is used, the SOAP messages can be sent and received without using a Web server. A Web server, which only handles HTTP requests, operates based upon the HTTP specification requirement that every HTTP request receive an HTTP response. This request/response model is not always necessary when sending messages; a SOAP message sender might need to send several messages and may not need or expect any return SOAP messages. The SOAP messaging in WSE accommodates this type of messaging, while still allowing developers to take advantage of the other features of WSE, such as digital signature and encryption support.

Visual Basic .NET Sample Code

The QuickStarts and sample code throughout the documentation are provided in both Visual Basic and C#.

XML Security Token Support

WSE 2.0 now provides support for XML security tokens, such as XrML and SAML security tokens. To use XML security tokens, you must create and configure a custom XML security token.

Version Compatibility

Web Services Enhancements attempts to maintain a degree of backward compatibility between versions. However, changes to WSE that help improve security, correctness, or functionality require rewriting portions of code when upgrading to the latest version of WSE.

The following is a list of areas containing breaking changes between WSE 1.0 and WSE 2.0

SOAP Messages Do Not Interoperate Between WSE 1.0 and 2.0

Messages sent between applications running WSE 1.0 and 2.0 generate a SOAP fault. A SOAP fault is generated because WSE 1.0 and 2.0 implement different Web services architecture specifications. Specifically, WSE 1.0 implements the WS-Routing and WS-Security specifications, whereas WSE 2.0 implements the WS-Addressing and OASIS WS-Security specifications.

Running Multiple Versions of WSE Simultaneously

Multiple versions of WSE can be installed and run on the same machine simultaneously. However, a Web service running on that machine can use only one of the versions. A single Web service client can interact with Web services running WSE 1.0 and with Web services running WSE 2.0. However, the client must use fully qualified names in the code to specify which version of WSE is being used. For example, the client could not specify SoapContext but would have to specify either Microsoft.Web.Services.SoapContext or Microsoft.Web.Services2.SoapContext.

Getting a SoapContext from Within a Web Service

To get a SoapContext from within a Web service in WSE 2.0, use the static (Shared in Visual Basic) Current property of the RequestSoapContext or ResponseSoapContext class for a SOAP request or SOAP response, respectively. For WSE version 1.0, the static (Shared) RequestSoapContext and ResponseSoapContext methods of the HttpSoapContext are used to get a SoapContext from within a Web service.

IPasswordProvider Interface Is Obsolete

You no longer have to build a class that implements the IPasswordProvider interface and configure that class when a Windows user account is used with a UsernameToken. WSE now supports Windows authentication for a UsernameToken. When Windows accounts are sent in the UsernameToken, a class does not have to be built and configured. However, when a Windows user account is not used with a UsernameToken, a class deriving from the SecurityTokenManager class must be built and configured.

DecryptionKeyProvider Class Is Obsolete

Shared-secret encryption (also known as symmetric encryption) is now done using a security token based on a symmetric key instead of just the symmetric key alone. Security context tokens, which are issued from security token services, are based on a symmetric key that can be used to encrypt SOAP messages.

Using Custom Binary Security Tokens in WSE 2.0

Custom binary security tokens built using WSE 1.0 require modification to be used in WSE 2.0.