November 22, 2004

WSE 2.0 SP2 PreRelease

A pre-release builds of WSE 2.0 Service Pack 2 is now available. The download links are:

Here's the content from the readme file:

Core product changes:


  • A new compatibility section is used to select the wire format on the sending
    side. The mode attribute tells WSE runtime to generate a message which will be
    compatibable to a particular release of WSE. By default, the mode is WSE2RTM. It can be WSE2RTM, WSE2SP1 WSE2SP2 and so on. On the receiving end, a particular version of WSE runtime will be able to accept all types of wire format in all its previous releases. In a request-response message exchange, a server will generate a response message which is compatible with the request message. The server will, by default, still use the compatibility section to generate its response if it cannot determine the compatibility mode based on the request message.
  • A new implementation of the Kerberos token based on SSPI interfaces is included in this release. The new token is named KerberosToken2. Please see the reference documentation for more details.
  • The TokenIssuer element in the KerberosToken security token assertion is
    no longer supported on the receiving end.
  • The SecurityTokenManager no longer throws exception in LoadTokenFromXml() when token.IsCurrent returns false. WSE security input filter will continue checking that and throw exception if token.IsCurrent returns false.
  • The inclusion of unencrypted Username tokens in a message may represent a security vulnerability. The SecurityTokenServiceClient class will now automatically encrypt any Username tokens included in a request. Similarly, the SecurityTokenService class will automatically encrypt any username tokens included in a response.

    The following methods have been added to the token issuing framework:

    protected virtual void SecurityTokenServiceClient.EnforceRequestUsernameTokenEncryption().
    Called from EnforceRequestPolicy(), this method enforces the requirement that any Username tokens in an RST message must be encrypted. The issuerToken is used as the encrypting token. This method will throw an exception if it cannot encrypt the UsernameTokens in an RST message.
    Override this method to suppress this behavior.

    protected virtual void SecurityTokenService.VerifyRequestUsernameTokenEncryption().
    Called from VerifyRequestPolicy(), this method verifies that tokens in an RST message are encrypted. This method will throw an exception if it encounters an unencrypted UsernameToken in an RST message.
    Override this method to suppress this test.

    protected virtual void SecurityTokenService.EnforceResponseUsernameTokenEncryption().
    Called from EnforceResponsePolicy(), this method enforces the requirement that any Username tokens in an RSTR message must be encrypted. The ResponseEncryptingToken is used as the encrypting token. This method will throw an exception if it cannot encrypt the UsernameTokens in an RSTR message.
    Override this method to suppress this behavior.

    protected virtual void SecurityTokenServiceClient.VerifyResponseUsernameTokenEncryption().
    Called from VerifyResponsePolicy(), this method verifies that tokens in an RSTR message are encrypted. This method will throw an exception if it encounters an unencrypted UsernameToken in an RSTR message.
    Override this method to suppress this test.

  • A new method, protected virtual void SecurityTokenServiceClient.ClearRequestSoapContext(), has been added. This method was added to fix a bug in which successive requests for a SecurityContextToken, made through a single instance of SecurityContextTokenClient, would fail. The problem was caused by a failure to clear security elements and tokens from the soap context after a request was made. In the event that a sub-class of SecurityTokenServiceClient requires that security elements or tokens in the soap context be preserved from one request to another, the new behavior may be suppressed by overriding the ClearRequestSoapContext method.
  • SoapService will now send back an empty SoapEnvelope back if the soap method it is invoking returns null for a request/response scenario.
  • EncryptedData.Decrypt will only support decryption to one and only one xml element. It throws a security fault otherwise.
  • In the SoapHttpOutputChannel.Send method, if the response has an unsupported content type, such as text/html, the response stream will be read and stored in the exception text.
  • Two new properties, SimpleDisplayName and FriendlyDisplayName, have been added to the X509Certificate class.
  • The default Label used in DerivedKeyToken has changed from "WS-SecureConversation" to "WS-SecureConversationWS-SecureConversation".
  • If an incoming message contains multiple security tokens with envelope signature inside those tokens, the server was returning a security fault. This is now fixed.
  • If WSE SOAP messaging stack is used over HTTP/HTTPS transport, a simple WSE805 exception was thrown when the response content type was not supported. Now if the response stream is readable, WSE runtime will read from response stream and throw a WSE805 exception with a more detailed error information read from the response stream.
  • WSE configuration section will now allow whitespace or comments as child nodes for the following configuration elements: diagnostics/trace, diagnostics/policyTrace, diagnostics/detailedErrors, referralCache/cache, security/x509, security/limits.
  • When a security context token was deserialized, WSE runtime will retrieve a token from its cache based on its globally unique Identifier. The token retrieved from the cache sometimes have a different Id than the token received from the incoming message. If that happens, WSE runtime would previously fail to verify a signature or decrypt the message. It is now fixed as it will assign the Id of the token from the incoming message to the token retrieved from the cache.
  • The built-in SecurityContextToken service would previously cache a newly issued security context token instance before those properties defined in the IIssuedToken interface are set. Now it is fixed so that those properties are set before the newly issued token is cached.
  • WSE runtime would previouly always generate a relative token reference in calculating message signature. When the token is not sent with the message, the receiver will return a security fault. It is now fixed so that an absolute token reference will be generated in the case when the security token is not in the message.
  • A server fault was thrown previously when a server tries to verify a signature or decrypt a message based on a username token which uses plaintext password option or no password option and does not have nonce and/or created element. The exception is now changed to be a client fault.
  • SoapService instances configured to automatically issue SecurityContextToken (SCT) security tokens no longer re-use the same instance of the SCT issuer. With this service pack, a new instance is created per request. This instance is accessible via the SoapService.AutoIssueSCTService property. If the old behavior
    is required, there are two work-arounds:

    1. override the SoapService.AutoIssueSCTService property to return a singleton instance of a SecurityContextTokenService, or

    2. create a wrapper SecurityContextTokenService that delegates to a singleton instance and register it through configuration.


Visual Studio tool integration changes:


  • The default value for http Routing handler type is updated.
  • WSE setting tool can support VS C++ project.
  • WSE setting tool would always prompt users for confirmation when the Cancel button was clicked. Now it is fixed so that the tool will prompt user only when some changes are made by users.
  • The Security Settings Wizard can support creating Policy files for remote service.

WseWsdl2 tool changes:


  • The WseWsdl2 tool now properly generates proxy classes when an Web service uses a Guid type.
  • If an input schema contains a type definition which is derived from another complex type, the proxy class would generate a class definition for that derived type with incorrect namespace. This is now fixed.

As always, please report any issues you have with the pre-release to the WSE Feedback mail address.

Posted by herveyw at November 22, 2004 05:38 PM
Comments

Interesting... that's good info to know.

Posted by: Baxter at November 24, 2004 06:04 AM

Does this release include Visual Studio 2005 support ?

Posted by: Olivier Van Pevenaeyge at November 25, 2004 09:01 AM