Partager via

WSE 3.0 Released on MSDN

  • Article

Having spent the last few months getting WSE 3.0 built, it is now live on MSDN here. This includes new Messaging and Security Hands on Labs (HOLs) to get you started on the new features. Next week there will be a WSE 3.0 overview article on MSDN

To provide feedback and suggestions on this WSE 3.0 release use the MSDN Product Feedback Center using the WSE product category.

To get support and ask questions on WSE 3.0 use the MSDN Web Services Forum

For those of you who are at TechEd 2005 next week I will be camped out at CSI cabana so come and find me and give me feedback on on WSE.

Enjoy.

New Features for Version 3.0

  • The introduction of Turnkey Security Scenarios that provide high level security building blocks that enable you to secure messaging patterns (such as request/response) rather than having to consider how to secure the request and response independently. These Turnkey Security Scenarios, otherwise known as security assertions, are best practices when securing end to end messages.
  • Improved Policy Framework
  • The Policy format has been simplified to reflect the Turnkey Security Scenarios. Policy still allows configuration-based declaration of security requirements for incoming and outgoing SOAP messages, but now concentrates on where to get the security tokens from based upon the chosen security assertion.
  • CLR attribute based programming. Policy files can now be associated with a client proxy or a service via a Policy attribute i.e. [Policy("ServerPolicy")]
  • Imperative and declarative programming models for policy have been aligned to provide uniform programming abstractions. In WSE 2.0 there was no correlation between the code written to secure a message exchange and declarative policy files. In WSE 3.0 through the use of the CLR Policy attribute and the SetPolicy method on WSE generated client proxies (via Visual Studio's Add Web Reference) policy files can now be used in code to secure a client or a service.
  • Policy also allows significant extensibility mechanisms for user-defined policies in code. By extending the Microsoft.Web.Services3.Design.PolicyAssertion class to create your own policy assertion, custom transformations of the SoapEnvelope can be performed at any stage in the pipeline. For example this enables you to define a logging assertion or have a policy assertion that enforces specified XML schemas for message validation. The same assertion can then be used in the declarative policy file.
  • An updated Security Settings Wizard that helps secure an application by generating a policy. The Security Settings Wizard also now reflects the Turnkey Security Scenarios when securing an application and walks you through the best choice of Policy assertion based upon your chosen security deployment.
  • ASP.NET Web services, otherwise known as ASMX Web services, can now be hosted outside of IIS, for example in console applications or NT services and called with the TCP/IP protocol. The existing lightweight, message-oriented, SOAP programming model SoapSender/ SoapReceiver classes remain.
  • Support for the W3C MTOM Recommendation to enable large amounts of binary data to be sent efficiently and securely.
  • Improved session management when using WS-SecureConversation and Security Context Tokens (SCTs). SCTs can now contain the original client authentication token when sent from the client to the service, which enable sessions to be re-established if lost e.g. when a service's appdomain is reset. This provides reliability for the session and enables sessions to be used in web farm scenarios.
  • WS-SecureConversation sessions can now be cancelled explicitly.
  • Integrated tool support with Visual Studio 2005 Beta 2. The WSE 3.0 configuration tool can be accessed via the context menu on the Visual Studio 2005 Solution Explorer.
  • Support for 64 bit runtime.
  • Support for updated Web services specifications including WS-Addressing, WS-Security, WS-Trust, and WS-SecureConversation. 
  • Updated QuickStart samples.

Comments

  • Anonymous
    June 03, 2005
    Don't get confused like I did -- this is indeed a CTP! ;)

    Any timeframe for final? We looking around the fall window when the other extremely cool stuff is coming out? ;)
  • Anonymous
    June 03, 2005
    The comment has been removed
  • Anonymous
    June 09, 2005
    Mark,

    Are <endpoint> and <operation> still supported somehow in the new policy file schema? The help page for <policy> (/policies/policy) refers to an <endpoint> element but the hyperlink is dead.

    Cheers,
    Dan
  • Anonymous
    June 21, 2005
    No, Endpoint and Operation (the ability to map in the policy file) are not supported in WSE 3.0. There has been a simplification of policy in WSE 3.0 and these were removed for the reasons of difficulty mapping messages to URLs and security exploits where the message could not have an default policy and this would still be processed through the WSE pipeline. Now you have to specific the policy name binding in code

    - Mark
  • Anonymous
    June 22, 2005
    Mark asked for some feedback on WSE 3.0 CTP. Here's my 2 cents. Switching on MTOM behavior: #1: all base64Binary fields are eligible for MTOM-ming. #2: You can control the behavior of the client or server using the mtom element...
  • Anonymous
    June 22, 2005
    Mark,

    See http://blogs.cocoondev.org/dims/archives/003213.html for feedback on the MTOM support.

    -- dims
  • Anonymous
    June 22, 2005
    Mark asked for some feedback on WSE 3.0 CTP. Here's my 2 cents. Switching on MTOM behavior: #1: all base64Binary fields are eligible for MTOM-ming. #2: You can control the behavior of the client or server using the mtom element...
  • Anonymous
    June 22, 2005
    Mark asked for some feedback on WSE 3.0 CTP. Here's my 2 cents. Switching on MTOM behavior: #1: all base64Binary fields are eligible for MTOM-ming. #2: You can control the behavior of the client or server using the mtom element...
  • Anonymous
    June 24, 2005
    Mark,

    Re: Endpoint and Operation

    So if I need to define the policy binding in code how do I define operation-level policy when PolicyAttribute cannot target a method (can only target a class)? I'm primarily interested in AuthZ. Within a named policy will I be able to specify different claim requirements for each action URI?

    Cheers,
    Dan
  • Anonymous
    June 01, 2009
    PingBack from http://uniformstores.info/story.php?id=15730