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