I love my user group!!!

I love talking to the Vermont.NET user group! These are my friends. It feels a lot more like teaching and sharing than presenting at a conference with a strict time limit to a group of people that may or may not like your presentation style and may or may not understand that you are there because you really truly want to help them understand something that is hard.

Tonight I spent 3 hours doing my WSE talk which is really two talks. Since our  meeting is 6-9, this wasn’t a bad thing. They were warned! Though not everyone lasted the whole 3 hours – I’d say 1/2.

First it is a whole presentation explaining the tools of security. The second part is an introduction to WSE2 along with explanation of some of the problems you may run into when you are not working in a perfect text book setting. It’s a little hard doing it at night since I myself started to get a little tired, but I kept checking, they wanted the brain dump so that’s what they got. It was really really fun and I know I really helped a good bunch of the people there. I got to answer every question that anyone had (it was a small group) which is something that you just cannot afford to do in a conference talk. There were a few questions that went a little deeper than my knowledge goes, but I answered with what I could and we decided to dig up the rest another time.

Even if I have to do it as two separate talks, I always want to do these together.

Posted from BLInk!

Tonight at Vermont.NET – Securing Web Services with WSE2

Last minute reminder on my talk tonight at Vermont.NET
 
Web Service Enhancements 2.0 was released in June. It can look very complicated but does not have to be!! Not only is WSE2.0 a valuable tool for securing web services *TODAY* (as well as implementing a number of the other Web Services specifications) but it is the path to Indigo.
 
This talk will be in two parts tonight. The first part is designed to ensure that we all have a good grasp of the tools of security – what is encryption? what is a digital signature? what is a digital certificate? etc. I’ll also make sure you know what a WS-* Spec is! I found that understanding these things made it possible for me to finally comprehend the articles and books I had been trying to read about WSE. Nobody had ever taken the time to explain these things well enough and I had felt like a bit of a dummy. So I want to explain it to you.
 
The second part of the talk will walk through the key elements of the WSE2 API, how to secure your web services with them and how to use the WSE Settings  tool to click your way to the most critical pieces of securing your messages across the pipe.
 
I have done this talk at the Montreal Visual Studio .NET User Group and at ASPConnections, so it is getting pretty well honed.


Posted from BLInk!

X509 Certificatates, WSE2 and JWSDP

I’m so happy I don’t have any *real* interop to do with WSE2 (yet). I want to learn it first, then dig into the harder stuff (and let’s not forget that this harder stuff, the interop, is the true intention of the WS* specs and therefore of WSE2, even if we do find it to be a nice neat way to deal with ws security in our .net to .net apps). Anyway, Simon Guest reports an issue with using X509 certificates other than the quickstart ones supplied with the SDK when interoping with JWSDP.

Posted from BLInk!

on DotNetRocks coming up

I guess I should mention that I will be on the live DotNetRocks this coming Friday.

Did you know there is a schedule on the site?

Kate Gregory was on a few weeks ago and Ted Neward and Mark Pollack were on this past Friday which is not posted yet. (update : oh, Ted & Mark were supposed to be on, but the show was delayed due to airline problems with Carl returning from Vegas or something like that…I think the word is that they will do it on Monday.)

Posted from BLInk!

Snow?

Halley Suitt is posting pictures that look like she has gotten at least 4″ of snow ther ein Boston. Here in Vermont it is COOOOOOL, but now snow! Apparently it snowed a bit on Thrusday but it was sunny so there was nothing left to show for it by the time I got home from Las Vegas.

Posted from BLInk!

RequestCachePolicy in .NET 2.0

Two of the new classes inside of System.NET.Cache are the HTTPRequestCachePolicy and RequestCachePolicy. It gives us some control on client side caching on a request by request basis. Since I think “web apps” when I think about caching, it took me some time to grok (with some help from a few folks at MS) what it’s real purpose is.

Of course, it doesn’t make sense that a webserver based app would have ultimate control over client side caching (wouldn’t that be cool though – magic, but cool!) As far as I know, only the client machine has knowledge of what is in its’ cache.

These classes are available for client and middle tier applications that are making HTTPWebRequests or FTPWebRequests and allow you to control how a webrequest is handled based on either the age of what is available in the cache or just by the location.

Since I do most of my interaction with a webserver via web services* or aspx pages, this doesn’t solve any problems that I am currently having, but it has given me some ideas of how I might leverage it in my applications.

Here are some ideas.

Say you have a web application that creates a pdf report and returns it to the calling client – maybe that is a windows app or even a web app that is the client. The data for this report does not change very much during the course of the day and it is a huge report. So you don’t realy want users taxing the webserver by requesting it more than once per day. You can tell the calling application to first check the local cache and if that download is in there and it is less than one day old, then it will not bother making the request.

Another example is for windows apps that actually use the web browser control. I have never had occasion to do this myself. But you can control how calls are made to the webserver to populate that control with instructions similar to the above sample – based on age or freshness – or you can instruct it to always go from the local cache under certain situations or always from the server. Or you can tell it that if there is nothing in the cache than get it from the server, but otherwise always get it from the cache. My simple demo on this only showed interaction with this funcationality. I had a web page that displayed the current time and you could see, for example, the time not changing for 5 seconds even though I was doing rapid-fire refreshes on the page.

This is not earth shattering functionality for the work that I do, but I can imagine that people writing applications for large corporations would benefit greatly from every tool that reduces the toll on the webserver. You can read more in this online documentation for .NET 2.0: Cache Management for Network Applications.

*re: web services – I REALLY wanted this to work with web services, but it just doesn’t. Although you can pass it the uri of an asmx file, there is no way to call the web method. I tried setting up the definition of the policy against the entire web service and then making a call to the webmethod, but it just didn’t work.

Posted from BLInk!

Vermont Shortbread Company

I just discovered a great local treat and am going to help my new pal (and proprietress) Ann Zuccardy by blogging about it (since it can be ordered for holiday gifts!) It’s the Vermont Shortbread Company. Their site is getting updated, but you can email Ann directly for pricing and shipping info!

Ann leads a double life as a technical writer, currently on contract at IBM, but she is a consultant –  which is how we got to chatting initially.

Posted from BLInk!

DevConnections Attendee views and get the DVD

Dave Bost got to do what I didn’t – attend sessions by some of the most awesome speakers on “the circuit” and then mine, too! I was busy working on my sessions so did not get to any. Here are his posts from Monday (Microsoft day), Tuesday and Wednesday with great details about the talks he attended. He also posted about the SQL Server and ASP.NET Keynotes by Tom Rizzo and Scott Guthrie. Dave is a user group leader who I knew from email, so it was fun to meet him.

They are making a DVD that can be purchased with all of the session from ASP.NET Connections and Visual Studio Connections, but not the SQL show. I believe it can be ordered through the registration page.

Posted from BLInk!

Digital Signatures at DevConnections

I had an awful moment in my WSE talk at ASPConnections thanks to great difficulty sleeping the previous night, so I want to be sure to write out my explanation of how a digital signature works here.

I have what I know is a terrific visual diagram to help explain digital signatures. What confused me when the slide popped up is seeing a private key next to the word encryption, which is correct for digital signatures but not for normal encryption. I had just walked the encryption diagrams and then hit the digital signing slide, saw that private key and my first thought was “but we don’t encrypt with a private key, we do it with a public key.” I really froze. In reality, my slide was right as I absolutely knew what I was talking about. Unfortunately i did not just allow myself to get past that moment of doubt. (which is a whole different topic about the balance of my knowledge, my presentation skills (both pretty good) and my confidence in them.)

So here’s the deal with why we are encrypting with the private key in this case. You can encrypt with any key you want, but you choose between them depending on your goals.

Encryption to achieve confidentiality: In this more common encryption scenario where we are trying to hide a message from prying eyes, we encrypt with the public key so that only the owner of the private key is able to decrypt. Anyone can see the message, but they won’t have the ability to decrypt it and view its’ actual contents.

Encryption as part of a digital signature: When digitally signing a message, we are creating a copy of the message body, hashing it (remember hashing can’t be undone) and then encrypting the hash. In the end, the validation is to ensure that the hash of the received message body matches this hash that we have sent along with the message body. If someone has mucked with the body or the hash (or both) there is no way that there will be a match on the other end. The encryption of the hash is done with a private key and then undone with the public key from the pair.

So this begs the question, why bother encrypting it if anybody can decrypt it? By encrypting with the private key, the recipient is absolutely assured that it was the sender (the only person with the private key) who created the digest. Think of this scenario: some devilish person could grab the message on its’ way, modify the message body and then create a new digest of that body. That would mean the digest would match the body when it’s received. But, that devilish person doesn’t have the correct private key to create the digest with. The recipient’s public key would recognize that immediately and the message would be invalidated.

So the process of signing doesn’t prevent anyone from mucking with the data (nor from even looking at the data – as this is the job of encrypting the message body), but just acts as a big red flag if the received message has been “violated” along the way.

Along those same lines, it’s good to note that encrypting a message body may prevent the wrong person from reading the actual data, but it is no guarantee that someone hasn’t taken the string of cipher text and altered it in anyway.



Posted from BLInk!