posts - 4238, comments - 3946, trackbacks - 370

My Links

News



Subscribe Subscribe

image image image





This is my personal weblog. These postings are provided 'AS IS' with no warranties, and confer no rights. The views expressed on this weblog are mine alone and do not necessarily reflect the views of my employer.

Licenza Creative Commons

Tag Cloud

Archives

Post Categories

WSE 2.0 SP3 Change list

Core product changes:

  • Security headers created by a SoapHttpRouter are now serialized onto the wire. Previously, when a SoapHttpRouter created a <Security> header with security tokens and child elements, the <Security> header would not be serialized onto the wire.

Security changes:

  • Policy enforcement for request and response messages have been made more secure by the following changes:

    • Incoming SOAP responses received by clients that do not contain WS-Addressing headers are now verified against the policy that is mapped for responses sent to the default (anonymous) role endpoint. When there is no default role endpoint specified, an exception is thrown. Previously, these SOAP responses were accepted and bypassed the policy verification check.

    • Server-side policies that utilize the IdentityToken attribute now work on SOAP faults and SOAP responses. Previously, policies applied to SOAP faults were not enforced when the SecurityToken assertion specified in the policy was an IdentityToken (from the Request) and therefore the fault response was not encrypted with the identity token.

    • When fault policy cannot be enforced on an outgoing SOAP fault, the SOAP fault contents are placed in an event log and a "server unavailable" fault is sent instead. Previously, SOAP faults would be sent in plain text when the policy associated with it could not be enforced.

    • A SOAP fault is now generated on incoming SOAP messages to a Web service that contain the same MessageID value as a SOAP request that is currently being processed by the policy system. Previously, an incorrect policy was enforced for SOAP responses from a Web service when two or more incoming SOAP requests were sent to different endpoints that had the same MessageID.

    • When policy is enabled, all endpoints that messages will be sent to or received from must have an associated endpoint policy. Previously, SOAP messages would be sent out regardless of there being no policy to enforce. Now you must explicitly specify that no policy should be enforced for a given endpoint in the policy file. Note that an empty operation element is now permitted (with the value of "" for policy defaults) or the empty defaultOperation element. This has the meaning of "do not apply policy for this endpoint".

  • When communicating over the soap.tcp or soap.inproc transports, authentication now correctly occurs when UsernameToken security tokens are used for authentication by a client and a server hosted in the same application domain. Previously, when the client and the server were hosted in the same application domain, no authentication was performed on the server when the client signed with a UsernameToken security token, because both the server and client were sharing the same UsernameToken security token cache.

Stress changes:

  • It is now possible to send a larger number of one-way messages to the same SoapService. Previously, sending a large number of one-way messages with SoapService hosted by ASP.NET caused a connection close to occur - leading to "Underlying Connection is Closed" exception on the client when under stress. This lead to the client exhausting all available ports as the client kept opening new connections for each request.

WseWsdl2 tool changes:

  • WseWsdl2.exe now correctly generates EndXXX proxy methods for overloaded method names. Previously WseWsdl2.exe would generate two EndXXX methods with the same method signature for overloaded method names.

Print | posted on lunedì 28 febbraio 2005 12:54 |

Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET