Category Archives: WSE

MTOM – Yep, it works

I am sending files to a web service in a vs2005 app using, of course, WSE 3.0. The only way I knew to prove to myself that it was really going up their using MTOM was to use Simon Fell’s TCP Trace program that I wrote about in this past post.

Here is with the MTOM “Client On” setting. Note the MIMEBoundary data and xop. That’s how the binary data gets sent with MTOM.

and here it is with the check mark off in the wse 3.0 settings. Note the lack of the MIMEBoundary info. If you saw the entire, contents of this, you would see the streamed data included – the array of base 64 bytes.

WSE3.0 and SoapContext.Security (obsolete)

In WSE2.0, the recommended way to do authorization, was to attach a principal with role information to a SecurityToken in a custom UsernameToken manager (which you would be using to authenticate against anything but A.D.). Then in your web method, you can just get at that principal by returning the Context.Security.Tokens from the RequestContext. But that is now obsolete. In fact if you use it, you will get a warning that SoapContext.Security is obsolete and to write a custom filter instead.

However the samples and the documentation in WSE 3.0 still show the old method. So, I’m not a Michele or Benjamin or William or Clemens or Christian. And most people using this stuff aren’t (cause those guys have all moved on to INdigo, but I have a live app that needs ws security…). Now what?

I guess I am going to learn how to use filters today. (so much for my fantasy of cutting out for 2 hours after lunch to go skiing because we got about 4 inches of new snow last night. whaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)

Don’t Forget: www.acehaid.org

Sample Certificates in WSE 3.0

For those of you who have used WSE 2.0 or all of the pre-RTM bits of WSE 3.0, we are used to having a folder with the sample certificates inside of the WSE 3.0 program folder. Not finding this with the RTM bits, I did find out where the certs were in the MSDN forums. Mark Fussell says:

The sample certificates were removed from the product and replaced with a setup.bat file in the \Samples directory. This setup file uses MakeCert.exe to generate named certificates, installs them into the correct certificate stores and set the appropriate priviledges when run. This was done to ease the installation on the samples and enable you to get started with the samples sooner

If you want to install certificates by manually you can follow the instructions either in the readme.htm in the samples directory or at the end of the Hands on labs. You can use MakeCert.exe to generate the same certificates as used to be shipped in WSE 2.0.

Now that I know where to look, I see that this information is in the readme document in the samples folder.

Don’t Forget: www.acehaid.org

WSE 3.0 to be release on launch day!

yippee!!

What this means of course is that I will be making some last minute changes to my presentation computer 1 day before I do my What’s new in WSE3.0 session at DevConnections. Hey, this is bleeding edge, right? I am willing to take the risk… 🙂

Currently I am running VS2005 RTM with the October CTP bits and having only one issue (which may or may not be related to the out of synch bits).

What is that issue you ask? I can’t seem to do encryption and signing when my webservice is on IIS. When it’s on the development web server, all is well. When I move it to the webservice, I get some wierd problem regarding “decryption” from the Cryptography API. (“Error occurred while decoding OAEP padding”.)  I have given all necessary permissions to the ASPNET account for reading the web server certificate and even as a last straw, gave “Everyone” full access to it. Hopefully, I will either get an answer to my question about this problem on the newsgroup or it will mysteriously disappear when I install the RTM bits. Or… I will have to skip that particular demo :-(, but since that session is in one of the 60 minute slots, that might be a good thing.

Don’t Forget: www.acehaid.org

TCP Tracing and WSE 3.0 – aha! Now I get it.

One of the interesting new features of WSE 3.0 is the use of MTOM and ability to transmit binary data as a Mime attachment. I have seen a few demos of this (one in Mark Fussell’s overview video, the other, a grok talk by John Bristowe) where they used different tcp tracing tools (check out this one from Simon Fell) to see what is truly happening to the attachment over the wire. Last month I tried using the tool that Mark had demo’d with and could never get it to work. Today I used the TCPTrace tool (that’s Simon’s) and was not seeing any messages come through the tcp trace.

This was because, as we all know by now, I am NOT a plumber. I could see Mark setting the Url to a different port in his demo, but when I did that, I was getting an error that my Addressing Actor (on port 8080) was not the same as the real service endpoint (on port 1932).

Mark’s article on What’s new in WSE3.0 even says “if you want to try this out, don’t forget to change the URI” but I could not figure out how.

After some googling I was noticing repeated references not only to Actor but to Via. This finally helped me find the solution.

The goal here (normally only explained in passing by all those plumbers who grok this stuff) is to create an extra little pipe for the message to go through. The trace tool can read from that pipe. We have to lay the one end of the pipe at the true service endpoint (in my case, the one that is on port 1932) and the other end of the pipe we can put on any port we want (I think any ol’ one, but I have mostly seen 8080 used and that’s what I am using myself.). In code, we tell the client where the true endpoint is (the Actor) and the port that we are detouring through (called the Via) . Then the message goes through that pipe where tcp trace is listening and does eventually get poured out into the actual web service. (This happens in reverse also).

So to make it happen, after creating a reference to the proxy in the client, we shove in this information about redirecting the ports:

‘be sure to reference the Addressing namespace

Imports Microsoft.Web.Services3.Addressing

dim wsproxy as new MyWebService()
wsproxy.Destination=new EndpointReference(new Uri(“http://localhost:1932/MyService/MyService.asmx), new Uri(“http://localhost:8080/MyService/MyService.asmx))

Then I tell the tracing utility to listen on port 8080 (my “Via” or detour) and that the destination is at localhost:1932.

And it works. And now I understand it – which I didn’t when I started. Just kept hitting my head with that plumber’s wrench until I figured it out.

Don’t Forget: www.acehaid.org

Lovin’ that wse3 policy

As I prepare for my last TechED SA session, What’s New in WSE 3.0, every time I hit a slide that focuses on policy or look at a policy file in the code, I think to myself “boy I love wse3 policy.” I really look forward to being able to do some conference sessions on just policy or articles in the near future as well as just keep blogging about it.

Posted from BLInk!

PAG releases CTP of WSE3 Security patterns

From the PAG Service Orientation workspace:

Just Released: October CTP featuring WSE 3.0! (10/15/2005 â€¢  News)
We invite you to check out the latest release of the Web service security patterns. This release is a substantial improvement over the past releases. We’ve added even more patterns and updated the implementation patterns to take advantage of the latest advancements in WSE 3.0. Please note that the WSE 2.0 implementation patterns have been removed from this release. We will add them back for the final release, but if you would like to review the WSE 2.0 implementation patterns in the meantime, check out the August CTP.

Developers can build secure Web services easier with WSE 3.0 by using its simplified and enhanced policy framework and by taking advantage of features in the .NET Framework 2.0. When you combine that with solid architectural, design, and implementation guidance, you have a much better chance of choosing an appropriate solution and saving some time in the process. While the WSE team just released the
WSE 3.0 October CTP, these implementation patterns were tested against the WSE 3.0 Beta build.

The following patterns have been added since the August CTP release. These patterns have all been through the workshop process, but haven’t all been through an initial editorial pass … that’s why it’s a CTP 😉

  • Message Replay Detection
  • Perimeter Service Router
  • Message Validation
  • Exception Shielding
  • Trusted Subsystem
  • Protocol Adapter
  • Delegation

As we are ramping up to release the final version of this content, we’re really depending on you, the community, to provide the feedback needed to make this the definitive resource for Web service security guidance. We would also love to hear from you if you’ve used this content as the basis for decisions you’ve made regarding your production Web services.

Don’t Forget: www.acehaid.org