Journey to robust webservices: kickstarting use of certificates phase II: using certificates for client authentication

There are a number of means of authenticating users, and one of the most secure is via a certificate. This article on CodeProject provides a start. Unfortunately, the article doesn't really mention a few things:

1. Depending on how you ran the tools, you may have inadvertently run the commands it gives you as an administrator. I ran them in a console that I already had open that was running as administrator, so they were installed as administrator, and I also happened to have been running in Visual Studio as an administrator at the time, so everything happily worked. Then when I rebooted my machine this morning and was running as a normal user, nothing worked, and I wasted over an hour trying to figure out why. That was why. Regardless of how you generated and installed the keys, you should go and explicitly grant permissions on the key to the users you want to have access to them. On the Microsoft website, there is a bundle of WCF samples (which you can find here). Included in the samples is a tool called FindPrivateKey. Download the samples, compile the program, and use it to find the key that you just generated. You'll need a command similar to the following : "C:\Samples\WCFWFCardSpace\WCF\Tools\FindPrivateKey\CS\bin\FindPrivateKey.exe My LocalMachine -t "28 ce e3 2c 7e 05 3a 97 a0 b4 92 fd d5 b0 f9 de 0e 4c 2e 4b"" where the value in quotes is the thumbprint of the non-signing (client) key you generated in the instructions from the article. Once it spits out the location of the file, you'll need to go and alter its permissions to allow whatever user your server / client application is running under access to the file.
2. Depending on the binding you're using with WCF on the server side, you may need to have a certificate with full chain trust on the IIS server (or other?) in order to use the binding (*cough* basicHttpBinding and any other transport-only security bindings *cough*). With that in mind, after you've generated the certificates in the article, while you're in the certificate manager MMC snap-in, you'll also need to copy (not move) the IIS developer certificate used in IIS to the "Trusted Root Certification Authorities" store.

Tomcat keystore : too many open files - Continued

Further to my last post, it seems there was another, larger underlaying problem that was causing the exceptionally high number of connections to our servers. One of our clients "required" (I use that term loosely because they really didn't the information) extra information for transactions that was not included in the optimized change metadata that they had been instructed to query for in order to update their transactions. So instead of just querying for the update metadata, they would do that, and then they'd query for each individual transaction. Assume we page our metadata at 100 transactions / page. For example, if we were to have a batch of 800 transactions submitted by the client, instead of making 800 / 100 = 8 calls to our server to update the transactions in the batch, they'd have 8 + (800 * 1) = 808 calls to update their system. They were effectively launching a Denial of Service attack on our servers each time they wanted to update a batch of transactions. Needless to say I consulted with them on the issue and updated our change metadata to include the information they "need" (which they've already got in their system), and they've updated their system to take the number of requests down to the proper level to update their transactions. So let this be a lesson to anybody reading this blog post that has to develop systems that deal with external clients : ensure your clients fully understand the purpose and intent of all the features of our system before they start developing for it and using it.