Windows Integrated Security in ASP.Net

I recently saw a story about how the new president of the US was interested in investing millions of dollars in "cybersecurity," whatever all that entails (and being your typical Slashdot reader, I didn't read the actual story). Maybe Mr. Obama's worried about the Borg selling national secrets to the Ayatollah.

We, the app developers, can improve the security of our public facing web apps by spending far less than...wait for it...one million dollars, and the solution is Windows Integrated Security.

Many people think of Windows Integrated Security as the SSO (Single Sign On) solution to save users the trouble of keeping Post-It sticky notes on the underside of their keyboards, and unbelievably inappropriate for web applications that need to be exposed to the public, but Windows Integrated Security is also good for securing Service Processes. You know, like IIS and Sql Server.

If you've never read up about security and performance scaling with web apps, you'll quickly discover in your initial research that using Windows security to authenticate the client, and then impersonating that client to authenticate to the Sql Server is very auditable and secure, but performs poorly under load. I think this is where most people give up and slap a password into their connection string.

Microsoft has a rather dry article on securing distributed applications using the Trusted Subsystem model, but for the typical single-server, single db web app, it boils down to this: use Forms Authentication to validate your user, set >identity impersonate="false"<, and assign your Asp.Net service account to some domain user account that pretty much can't do anything useful on the web or database server. This is easier done than said in newer versions of IIS, since all you have to do is set the user account of the relevant IIS app pool. In 32 bit XP (yeah, 64 bit XP comes with a different version of IIS from 32 bit) and Server 2000, its a bit more convoluted, since the version of IIS that comes with them is Old-N-Busted(TM). You will end up editing that spooky machine.config file to make SERVER\ASPNET stop being Asp.Net's man of the hour.

Oh, and don't forget to run aspnet_regiis -ga [domain account] on your web server, or you'll get mad at it. I really don't know what all, specifically, that command does, except that it "Grants Access" for everything a budding young domain account would need to actually run Asp.Net in IIS.

Once you have your IIS process running ASP.Net under a domain account, its trivial to grant that account whatever access is needed in your Sql Server. And guess what? No passwords in the connection string for some nosy junior coder to be copying down to break your production database. Million dollar cybersecurity, all for free.