This is one of the most frequently asked questions on the newsgroups.

Since Verisign and Thawte do not speak "message-based security", people are always confused about buying SSL Certificates for doing WSE or WCF.

It's not just the vendors. Sometimes the people responsible for your networks are also hard to convince since message-based security just does not make sense in their world. They may not know which one is right either.

What have you had success with? What actual certificates (literally the name that the vendor applies to the cert) have you purchased from which vendors? There's a myriad of choices, but it's never easy to pick.

 

On Thursday evening I gave a talk on WS Security Fundamentals in Dayton Ohio. One of the resources I point to is the PAG Guide on Securing Web Services. On the way home the next day, while sitting on the runway in PHL for 2 hours before taking off (uggh), I was reading the latest ASPNET Pro and Michele Leroux Bustamante's Under the Hood column was all about X509 cert management. It's great advice and I highly recommend it. It's the October 2006 issue which does not have all of its articles online.

Many developers who are starting up with programming message level security (eg with WSE or WCF) definitely have a learning curve when it comes to having to grok all of these bits and pieces of security tools that we have to work with - encryption, hashing, signing, certificates. I don't know how many times I have seen the question "where do I get a certificate" in the wse newsgroups. Heck, I had the same question myself once. And it was a lot of work to wrap my head around all of this crypto stuff.

So.... if you get ASPNET Pro or you can grab a copy at your local user group, check it out.

I'm going to send this to the sysadmin that works with one of my clients. I spent three months trying to explain to him why I needed a server certificate that was not going to be used for SSL. Aargh. Message level security seems to be a bit of an oxymoron to IT Pros.

I was happy to find this very current slide denoting the status of the various WS-* specs. I got to use it in a WS-Security fundamentals talk that I did in Dayton Ohio last night.

http://blogs.msdn.com/jevdemon/archive/2006/08/02/686515.aspx

I learned this the hard way, as usual.

We had to change the X509 Certificate that we were using for our application. That meant that the policy config file on the client and the app had to have the certificate identity defined by the findValue parameter of the X509 node.

<serviceToken>
<x509 storeLocation="LocalMachine" storeName="My" findValue="CN=MyCertificateName" findType="FindBySubjectDistinguishedName" />
</serviceToken>

I made all of the necessary changes and ran the client app. I received an error from the server:

"WSE2006: EncryptedKeyToken in the security header of the incoming message is encrypted with a different security token than expected."

That's telling me that the certificate on the client side doesn't match the certificate on the server side. After triple checking my setup and configuration, I went to turn tracing on on the server side to see what the heck was going on. This meant modifying the web.config. Suddenly the app worked.

Editing web.config forces an app restart so this made me realize that the policy file must have been getting cached in the AppDomain and the restart forced the revised policy to be read. Mark Fussell confirmed that to be the case.

I have posted my version of the powerpoint (not the pretty MSDN version since I don't have that) and the sample code from today's Intro to WSE 3.0 webcast.

You can find them on my TALKS page. Scroll down to Introduction to.... and you'll see the zip and ppt files.

Thanks to all who attended!

I hear there was a snafu with the survey and MP3 Raffle and that emails will be sent out to attendees on how to get back in the game (within 24 hours, they told me)

As part of the Web Services Webcast Series, I'll be doing an Intro to WSE 3.0 tomorrow morning at 11am.

It will be a 1 hour session on the key features of WSE 3.0 with as many demos as I can cram in!

There's an MP3 raffle for attendees of this series. Check it out!

Here is the whole series. Please don't ask me why the series of web casts on Web Services (WSE, ASMX, and lot of WCF, of course) is called "Windows Vista: Improve your Deployment and Security Strategy", but at least it's under the WCF section, since it's like a WCF starter kit for those who can't wait until WCF is live!

See you tomorrow!

Kirk Allen Evans has organized some of the top WCF/Web Services gurus (and me,too!) to do a web cast series through June.

For those of you securing web services TODAY, my webcast will be Overview of WSE 3.0 . June 8th at 11am EST (that's 8am PST).

More info here

Also oooh aah a raffle for attendees!! Attend any webcast in this series and qualify to win a 40 gigabyte Creative Zen MP3 player (official rules).

Here is the full of the schedule

“The Lifetime of a Message in Windows Communication Foundation”

Justin Smith, Wintellect

6/1/2006 8:00 AM PST

http://msevents.microsoft.com/cui/eventdetail.aspx?eventID=1032299306&Culture=en-US

 “Taking Advantage of TCP/IP Reliability in SOAP”

William “Softwaremaker” Tay

6/6/2006 8:00 AM PST

http://msevents.microsoft.com/cui/eventdetail.aspx?eventID=1032299329&Culture=en-US

 

 “Extending Windows Communication Foundation”

Aaron Skonnard, Pluralsight

6/7/2006 8:00 AM PST

http://msevents.microsoft.com/cui/eventdetail.aspx?eventID=1032299313&Culture=en-US

 

“Introducing Web Services Enhancements for Microsoft .NET (WSE) 3.0”

Julie Lerman, The Data Farm

6/8/2006 8:00 AM PST

http://msevents.microsoft.com/cui/eventdetail.aspx?eventID=1032299315&Culture=en-US

 

“What’s New for ASP.NET Web Services (ASMX) in .NET 2.0”

Kirk Allen Evans, Microsoft Corporation

6/13/2006 8:00 AM PST

http://msevents.microsoft.com/cui/eventdetail.aspx?eventID=1032299322&Culture=en-US

 

“Dissecting Contract-First Web Services”

Christian Weyer, thinktecture

6/14/2006 8:00 AM PST

 http://msevents.microsoft.com/cui/eventdetail.aspx?eventID=1032299331&Culture=en-US 

 

   “Transactions in Distributed Solutions with Windows Communication Foundation”

Christian Weyer, thinktecture

6/15/2006 8:00 AM PST

http://msevents.microsoft.com/cui/eventdetail.aspx?eventID=1032299342&Culture=en-US

 

“Building Powerful AJAX-Style Solutions with ASP.NET "Atlas" and Windows Communication Foundation”

Kirk Allen Evans, Microsoft Corporation

6/20/2006 8:00 AM PST

http://msevents.microsoft.com/cui/eventdetail.aspx?eventID=1032299344&Culture=en-US

 

“Exposing Your Content as a Service Using Windows Communication Foundation’

Clemens Vasters, Microsoft Corporation

6/21/2006 8:00 AM PST

http://msevents.microsoft.com/cui/eventdetail.aspx?eventID=1032299346&Culture=en-US

 

“Web Services Interoperability with Java and J2EE Using Windows Communication Foundation ("Indigo")”

Kirill Gavrylyuk, Microsoft Corporation

6/22/2006 8:00 AM PST

http://msevents.microsoft.com/cui/eventdetail.aspx?eventID=1032299348&Culture=en-US

 

“Understanding Windows Communication Foundation Contracts”

Michele Leroux Bustamante, IDesign

6/28/2006 8:00 AM PST

http://msevents.microsoft.com/cui/eventdetail.aspx?eventID=1032299360&Culture=en-US

This has always been a big point of confusion, both for developers (like me) and admins.

SSL Certificates are misnamed. They are not for SSL only. I wish all of the CA's would just call them "Web Server Certificates". How and where you install them determines whether or not they are used for SSL.

I remember my first conversation with tech support at Verisign trying to find out how much one cost. This was when I was playing with WSE 1.0. I was extremely clueless. The conversation went something like this:

me: I'm trying to find a server certificate to use for Web Service Enhancements

them: huh?

me: I think it's just called a "web server certificate". You have SSL certificates, but I don't want SSL. I'm not doing SSL.

them: huh?

It went on for a while.

I finally learned that the trick was just to buy an SSL cert, install it on the server and don't bother with the IIS intallation of it. That's what I do.

I couldn't figure out how to explain this to an i.t. person who is used to SSL. They were very wary of installing it on the web server because I wanted to do something wierd with it.

With WS-Security picking up more steam and WCF around the corner, I think thre are going to be many conversations like this in the future. If they just called them Web Server Certificates, it would prevent a lot of frustration out there in the world of web service developers.

Don't Forget: www.acehaid.org

What? I'm still writing about that worn-out old non-technology, WSE 3.0? Darn right I am. [read more...]

[A DevLife post]

Don't Forget: www.acehaid.org

I recorded my basic "Securing a web service with WSE 3" demo using Camtasia. There are two versions of this.

1. In the 30 minute version (25MB), I spend a lot of time looking at config and policy files as well as tracing and debugging while implementing the security.
2. The shorter 15 minute version (12MB) does not take any stops along the way although we do inspect the trace file at the very end  just to prove that the message was secured.
3. WCF Client to WSE3 Service Demo (20MB, 20 minutes) see notes below

I don't get to take this much time to explain things during a conference, so I'm happy to be able to do the demo in my own time frame. I think I will do this for some of my other favorite presentations.

It's different to do a presentation with no audience, in the quiet of my office. I did have to edit out the barking dog at one point. It's not nearly as fun and I can tell that I sound very different than when presenting to a room full of developers. Maybe I should drink a few cups of coffee next time I record demos. Also, without the conference clock ticking away, I am not racing through the demo which is a nice change. Calm cool and collected.

Next I will record the demo of my WCF client calling into a plain ASMX web service built in .NET 2.0 with Visual Studio 2005 and then calling into a web service that has been secured with WSE 3.0. When that is online, I come back to this post and link to that as well.

Update 4/18: The WCF demo is online. It is 20 minutes long and about 20 MB. There are two important things to know about this demo. 1) It is part of a bigger presentation about writing web services today that can communicate with WCF tomorrow, but the demo doesn't go over those rules. You can see basic guidance in this article that I wrote, but becuae the guidance was in flux when I published the article, please do keep an ey on he MSDN WSE Dev Center for an upcoming article by William Tay and PAG guidance. 2) This is not focused on how to write the WCF client. Although I show a little about how I did it, the point of the demo is just to prove that it works. Again, watch for William Tay's article!

Don't Forget: www.acehaid.org

Not only can you write web services today that can be consumed by WCF (Indigo) apps in the future, but working with WSE 3.0 today to secure your web services will also help you get a handle on many of the concepts of WCF. I have written an article for DevSource called "Using WSE 3.0 Today to Secure Web Services Tomorrow" based on current guidance (based on WSE 3.0 and WCF Beta 1) on just such a topic.

I will also be doing a talk on this topic next week at DevConnections.

Thanks to Mark Fussell for his insights on this topic.

Don't Forget: www.acehaid.org

Pablo Cibraro (who should be an MVP) is, in my opinion, one of the most knowledgable WSE guys around. He is up there with Michele and Softwaremaker (who have both moved on to be WCF gurus, of course). But besides having a wealth of practical knowledge, he spends an inordinate amount of time sharing it in the WSE newsgroups, answering myriad questions and following up on many of them.

He has answered questions for me too.

But today, he really impressed me even more. I was runing up against a problem that I could not figure out or find the answer to anywhere. In fact, I found two other questions on the web with the same problem but no answers.

The more I dug into the problem the more I learned and I finally was able to google the right keywords. And where did I find the solution to my problem? In Pablo's blog (see below). He does not post very often, but boy am I glad he wrote about this. I had even been fiddling in the right section of my web.config file, but just wasn't tweaking quite the correct thing.

So thanks Pablo!

And for google's sake, the problem was some encryption being done in a request for a securityContextToken in WSE3.0. On Windows 2000 machines, it was encrypting the requested key with RSA15, but WIndows XP clients were encrypting with OAEP and the win2003 server was expecting OAEP.

Windows 2000 does not have the ability to wrap with OAEP. So I had to force all clients to wrap security tokens with RSA15 (Win2000 will do it by default, but XP won't) and then force the server to use RSA15 also.

But I couldn't figure out how. Pablo's post on using the web.config in WSE 3.0 to override the default encryption led me to my solution. He also followed up with a reply in the newsgroup as I was typing this very post.

The error

An unsupported signature or encryption algorithm was used --->
System.Exception: WSE3002: The receiver is expecting the key wrapping algorithm to be http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p, but the incoming message used http://www.w3.org/2001/04/xmlenc#rsa-1_5. You can change the key wrapping algorithm through configuring security token manager.

The solution in both web.config of the service and app.config of the client (inside of the security tags of the microsoft.web.services3 tags):

<binarySecurityTokenManager>
    <add
valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
     <keyAlgorithm name="RSA15" />
    </add>
   </binarySecurityTokenManager>

Don't Forget: www.acehaid.org

I had an email today from someone asking this question. They have a web service and a client app that use WSE2 to encrypt, sign and otherwise secure their data.

However, they were able to open up the asmx file, the operation and look at raw xml data in a web browser over the web. No authentication, no encryption, no signing. I could see it, too!

What a nightmare after all of the work to secure this data.

The reason for this problem was another case of debugging tools getting deployed to the production web server. Something I tend to rant about occasionally.

In order to browse from their development machine to the web service on a remote web server, they had added

<webServices>
 <protocols>
   <add name="HttpGet" />
   <add name="HttpPost" />
 </protocols>
</webServices>

and left them in the web.config when it was deployed to the server.

I was able to guess this pretty quickly since I once learned this the hard way, too. Sadly most of our best lessons are the ones that leave bruises. 

For some more web.config tricks to hide your web service from public view as well as the wsdl, see this msdn doc on configuring web services for deployment.

Don't Forget: www.acehaid.org

I saw this question in the newgroups and wanted to blog about it because it is a real gotcha that gotme too when I first started working with WSE 3.0.

If you set the WSE 3.0 diagnostics tab to output trace files, you can get a look at the messages going out of and coming into your client as well as going out of and coming into your webservice.

Tip #1 Remember to turn OFF this tracing when you send your client app or web service into production. Left to it's own devices, the trace files will grow and grow and grow and one day you will be wondering why your web service is acting so slowly. That's because of the effort of opening up a 60MB file to add some text to the bottom of it!

Tip #2 The default file names are TraceInput.webinfo and TraceOutput.webinfo. Those extensions suck because you can't open them up in anything easily. I always change them to TraceInput.webinfo.xml and TraceOutput.webinfo.xml. Then I can double click on them and open them up in something like I.E. or an even more intelligent angle bracket reader. (Note:Nathan (a tester on the WSE team) makes a good point about this. If you forget to do #1, then #2 could very easily expose some super critical data for hackers on your production server! So you might be better off without this particular little trick of mine.)

Tip #3: Reading the trace files, remember that there is more than the header and body of the message in there. There is also processing info. That means that in an output file, the first thing you will see is the unprocessed message. Your app has created the message, but it hasn't been through WSE yet to get all it's protection before it's sent out on the wire. This is very confusing and can even be a little frightening because if you have encrypted your message, the first thing you see is a message body with clear text! Notice,though, that it is surrounded by tags that say <processingStep description="Unprocessed Message">. Now at the bottom of that <outputMessage> and you will see the <processingStep description="Processed message">. That is the message that is going out on the wire and hopefully looks more like what you expected.

On the incoming message, the first thing in the door (again the Unprocessed Message) is what just came in off the wire. So that is the real soap message and should display all of the properties you expected - encryption and any thing else you demanded of the message. Then you can read through the processing steps and the last step has the fully processed message that is about to get passed to your application. All of the security goo is gone and you will see clear text again, even when the actual message was totally secured.

Tip #4: If you want to see only the soap that went over the wire, bag the built in tracing and use Mike Taulty's sweet little WSE 3.0 Tracing Tool.

Tip #5: For even more detailed inspection and diagnostics of your web service messages, check out Mindreef's SoapScope.

Don't Forget: www.acehaid.org

Three years ago I did a presentation at Vermont.NET on Architecting Applications with Web Services. (Proof is at the past events page - check Feb 2003!) 

I clearly remember the question of overloaded web methods coming up in that session. I didn't know the answer so I tried it right then and there and it didn't work. Someone mentioned there was a way to get around it and we found that solution another day.

It's still a question for a lot of people who are coming to Web Services as OO programmers (which Visual Studio lets us do) and that is because many are unfamiliar with the attributes that can be used for web services. Or they see them but have no idea what they are there for.

Thom Robbins recently had someone ask the same question and blogged how to use attributes to enable overloading when defining web methods in Visual Studio.NET.

Three years ago, it seemed like a good idea to me. I didn't really grokWeb Services. I was just using them as a means to an end and I knew OO programming, not messaging.

However, now my perception has changed and it's important to note (as Thom does (thanks Thom!)) that just because you can do it, doesn't mean it's a good thing. It's the OO way, for sure, but it just does not jibe with messaging and contracts and it does not conform to WSI Basic profile which demands unique names for operations (web methods). So if you have any intentions of going outside of .NET with your messaging, don't do it. A contract needs to be clearly defined and by providing overloads, that just blows the contract away.

If you are writing what the plumbers call "silo" apps, .NET all the way through and you are controlling the client and the service, there's no harm outside of the damage you are doing to your brain. Still, it's important for the WSDL that represents your web service identifies does not identify itself as conforming to WSI Basic profile. When you create a new web service in VS2005, by default, the service has attributes that claim to conform to the Basic Profile. Thom includes the caveat in there to set the services' conformance claims to "none".

Here's what a .Net web service class that shows what Conformance Claims  looks like. ConformsTo is the claim. Emit embeds the claim in the wsdl.

<WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1, EmitConformanceClaims:=True)> _
<WebService()> _
Public Class ShowConformance
  <WebMethod> _
  Public Function HelloWorld() As String
   Return "Hello"
  End Function
End Class

If you look at the wsdl (eg http:\\localhost\myservice.asmx?wsdl) you can see that claim. Here is the appropriate section of the wsdl.

When you explicitly define that the service does NOT conform, there is no claim in the WSDL that says "I do not conform". In that case, no claim is made at all.

So by marking your service with

ConformsTo:=WsiProfiles.None

even if you have EmitConformanceClaims set to true, there will be no wsi:Claim in the wsdl.

If you forget to remove the conformance claims, you will get a big fat error message when you try to call the asmx.

Service 'Service' does not conform to WS-I Basic Profile v1.1. Please examine each of the normative statement violations below.

and the detail tells you:

To make service conformant please make sure that all web methods belonging to the same binding have unique names.

The more you start understanding these things today, the more prepared you will be for WCF.

Don't Forget: www.acehaid.org

I was pushing a new WSE 3.0 web service to a test web server. Whenever I tried to authenticate I was getting "Security Token could not be retrieved" from the server.

WSE590: Failed to resolve the following Key Info .....

I knew the sample x509 server certificate was installed. I knew I had assigned read permissions to Network Service with the Certificate tool that comes with WSE.

It took me quite a while before I realized I had installed the certificate that came with WSE2 which is different than the certificates I had created with the WSE3 Setup in the Samples.

The data that made me finally realize it was that in the error message, it referred to the SHA-1 key identifier that the client had sent to the server to look for. But that was not the id of the server certificate.

So I uninstalled the wrong certificate and installed the correct one.

Now, as a test, I did not give permission to the Network Service account to access the certificate.

The message was very different:

WSE600: Unable to unwrap a symmetric key using the private key of an X.509 certificate. Please check if the account 'NT AUTHORITY\NETOWRK SERVICE' has permissions to read the private key of certificate with subject name 'CN=WSE2QuickStatServer' and the thumbprint.....

Now how specific is that? So I am now more confident that "security token could not be retrieved" is literally about FINDING the token, not using it, which can save me a lot of time if I make that mistake again!

Another thing that messed me up was that I had originally installed the certificate into the Current User's store but I wanted it in Local Machine. You need to export and import certificates to make them work properly. But I didn't know this and just dragged and dropped it to the Local Computer's Personal Store instead. That was a no-no. The documentation (see the note in "How to: Make X.509 Certificates Accessible to WSE") explains that when you do this, even if you use the certificate tool (or other means) to apply the ASPNET or NETWORK SERVICE perms, it won't work. That is because the file associated to the certificate (and it is the file that is getting the permissions) does not get moved along with the certificate.

Don't Forget: www.acehaid.org

WSE 2.0's messaging API gave us the ability to host web services outside of IIS. Though it was very cool, I didn't dig that too much because you had to give up all of the other WSE goodness that only worked in ASMX - including security.

In WSE 3.0, they changed this so that you could build ASMX web services, do all of the great security stuff and then host it outside of IIS - for me this meant TCP, though there are other transports you can use as well.

Now that I am using WSE3 to secure my web services that are currently being used (while we await WCF ), I am trying to do so with WCF in mind. It is no secret that WSE 3.0 is going to be wire level compatible with WCF as this is was of it's major design goals.

As I dig further into this, I learn that this is only true for HTTP but not the TCP hosted services. However, it is possible to write your own transport channel in Indigo specifically for this purpose and this is something that Yasser Shohoud and Kenny Wolf did at PDC (here's the code for that). Luckily for me, I have the DVD because that was not a session I attended. I also missed Mark Fussell's talk on moving messages between WSE 3 and Indigo since I had remembered it as a 10:15 session when it was in fact an 8:30 am talk (and had a leisurely breakfast instead - oops!). (Again, thank goodness for the DVDs)

At ASP Connections in April, I will be doing a talk about using WSE 3.0 so that the messages produced by WSE 3.0 today to secure your web services,  will still be valid when communicating with apps that use WCF.  So as I prepare for this, I will probably be sharing tidbits here and there.

Don't Forget: www.acehaid.org

Don Smith, Mark Fussell, Ron Jacobs and Dwayne Wright are doing webcasts on securing web services with wse 3.0.

The first, Securing Web Services with X.509 Certificates in WSE 3.0, is already on line.

They will be doing one on Kerberos this coming Wednesday, Jan 18th, and then another with UsernameTokens on Wed Jan 25th.

Stay tuned here.

 

Don't Forget: www.acehaid.org

By process of (hours of) elimination I have solved a problem that was driving me batty today!

I have a WSE 3.0 enabled client app that calls a WSE enabled web service.

After creating a UsernameToken, the client application was setting the credentials on the web service proxy using the generic overload:

proxy.SetClientCredential(Of UsernameToken) (myUT)

As I built the tests up one by one everything was working swimmingly... until I added in the SecureConversation into the client and service policies. (establishSecurityContext="true").

Then I was getting a 401 Access denied whenever I tried to hit the web service. I could see through the status of the tracing that I was not even touching the web server on these calls.

Setting the SecureConversation to false let everything work again.

I spent quite a lot of time experimenting and scrutinizing my settings, configs, etc.

I even loaded up the sample application for Secure Conversation which worked perfectly fine.

Both web services were in IIS and I compared everything. config files, policy files, IIS properties and security, folder security.

Combing through these, I tested every little thing that was different - folder access permissions and more. I explored differences in code such as setting the soapversion explicitly on the proxy. Nothing made a difference.

But finally, I came upon the nominal difference that was causing the problem (though I have no explanation for it).

It was the use of generics in setting the ClientCredential on the proxy.

When I used the non-generic method, as the sample uses:

proxy.SetClientCredential(myUT)

instead of

proxy.SetClientCredential(Of UsernameToken) (myUT)

suddenly I was getting a response from the server. It was still an error, but I knew I was finally getting through to the server.

The new error was my method of doing authorization on the token. This new token was "just a securityContextToken" and not a UsernameToken.

In my web service, I had cobbled together some old WSE 2.0 authorization code with some WSE 3.0 code which looked like this

dim tok as UsernameToken=RequestSoapContext.Current.IdentityToken

if tok.Principal.IsInRole(....blah blah blah

When attaching the credentials using the generic method, IdentityToken was returned as a UsernameToken, but now it is not. It has a base of UsernameToken, but it doesn't cast (I tried) to UsernameToken.

I can get the principal directly from IdentityToken anyway, so I just modified that code

dim tok as SecurityToken = RequestSoapContext.Current.IdentityToken
if tok.Principal.IsInRole(....blah blah blah

This cost me many many hours. At least now there will be something for Google to find!!

Don't Forget: www.acehaid.org

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.

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

Now that WSE 3.0 is released, the next step is WCF, so I'm happy to see that Mark Fussell has moved from Program Manager of the WSE team onto the WCF team and is working on WCF security.

Don't Forget: www.acehaid.org

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

Christian Weyer convinced me not to update my demo computer from WSE3 October CTP to WSE3 RTM when I have my WSE3 session this afternoon. I promised not to. BUt that just takes all the fun and challenge I could have added to my day (read just a little sarcasm into that statement...)

Posted from BLInk!

WSE 3.0 is now fully released. Thanks to Mark, Sidd (the two I worked with most closely) and the whole team for all the work on this great product that I love to love. Hmm, I wonder if my session on Thursday will be the first presentation to use the full release of wse 3.0? Too bad it's only a one hour slot...

Posted from BLInk!

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

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

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!

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

Sounds like Paul Glavich was trying to manually process an incoming email message and get it into the pipelline. Finally he gave in and used the built in goo: Pipeline.ProcessInputMessage(soapEnvelope) and WSE did it's magic. Apparently it was some white spaces that were eluding him, but the WSE method knew how to deal with them.  BTW - he's doing this in WSE3, but this is also a class and method available in WSE2. I have never had to use it before, so this is a great thing to know.

Don't Forget: www.acehaid.org

Although I missed Mark's talk at PDC last Friday, I was still highly entertained by watching (again) his WSE 3 Overview talk from the WSE 3 SDRs. Mark has a lot of fun acting out many messaging scenarios such as timing out a telephone conversation with his mother to demonstrate a new feature for SecureConversation. It may seem silly, but he has great methods of taking concepts that may be confusing and putting them into a context that many people can understand. You can watch this video yourself. There are a bunch of them on the home page of the Web Services Developer Center.

I am giving a similar talk Sunday at Code Camp and then at TechEd South Africa and once more at DevConnections. Mark is a tough act to follow. Being the pm on the WSE team and having a serious background in XML, he knows this stuff inside and out.

Don't Forget: www.acehaid.org

I have been meaning to mention how cool and informative the info is in the WSE3 trace files. Not only does it show you the soap, but leaves a step by step trail of processing. Here is a sample file from a simple HelloWorld request being made from a client using a UsernameoverX09 policy asserstion.

<?xml version="1.0" encoding="utf-8"?>
<log>
  <outputMessage utc="9/23/2005 7:04:53 PM">
    <processingStep description="Unprocessed message">
      <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <soap:Body>
          <HelloWorld xmlns="http://tempuri.org/" />
        </soap:Body>
      </soap:Envelope>
    </processingStep>
    <processingStep description="Entering soap filter Microsoft.Web.Services3.Design.UsernameOverCertificateAssertion+ClientOutputFilter" />
    <processingStep description="Exited soap filter Microsoft.Web.Services3.Design.UsernameOverCertificateAssertion+ClientOutputFilter" />
    <processingStep description="Processed message">
      <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
        <soap:Header>
          <wsa:Action wsu:Id="Id-3055d475-5038-45ae-9909-d7feb1241b7b">http://tempuri.org/HelloWorld</wsa:Action>
          <wsa:MessageID wsu:Id="Id-bc312d98-8815-4c65-a015-2cf87409140c">uuid:80c57c6f-7226-49a6-95ba-51c160841d30</wsa:MessageID>
          <wsa:ReplyTo wsu:Id="Id-d3c52946-1153-4ef6-85df-4e80506bb0a2">
            <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
          </wsa:ReplyTo>
          <wsa:To wsu:Id="Id-047058e6-d0e9-4592-8d10-2df4cd13d976">http://localhost:1624/WSE3_Demo2_Service/Service.asmx</wsa:To>
          <wsse:Security soap:mustUnderstand="1">
            <wsu:Timestamp wsu:Id="Timestamp-71acb0d5-9d5c-4d6d-beba-585045011528">
              <wsu:Created>2005-09-23T19:04:53Z</wsu:Created>
              <wsu:Expires>2005-09-23T19:09:53Z</wsu:Expires>
            </wsu:Timestamp>
            <xenc:EncryptedKey Id="SecurityToken-2eb49508-1d19-4dc8-ac98-df6037e4dce3" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
              <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
              <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                <wsse:SecurityTokenReference>
                  <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-x509-token-profile-1.1#X509ThumbprintSHA1" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">h9ksyrcUww2w4LrmubC2W11t988=</wsse:KeyIdentifier>
                </wsse:SecurityTokenReference>
              </KeyInfo>
              <xenc:CipherData>
                <xenc:CipherValue>(this goes on for a while...) Udj=</xenc:CipherValue>
              </xenc:CipherData>
            </xenc:EncryptedKey>
            <wssc:DerivedKeyToken wsu:Id="SecurityToken-a4ae21b8-bdab-4011-a7b2-c5e8f65bae44" Algorithm="http://schemas.xmlsoap.org/ws/2005/02/sc/dk/p_sha1" xmlns:wssc="http://schemas.xmlsoap.org/ws/2005/02/sc">
              <wsse:SecurityTokenReference>
                <wsse:Reference URI="#SecurityToken-2eb49508-1d19-4dc8-ac98-df6037e4dce3" ValueType="