It's wonderful to see this sort of critique finally emerging from within Microsoft, and I very much hope that you're right about the quality of future sample applications.

That said, there are a couple of potential errors/omissions in your article that might merit a second look. The more obvious of the two is the last sentence of the CAS section, which essentially states that link demands for SNIP (StrongNameIdentityPermission) can't be bypassed even by fully trusted code. Unfortunately, that's simply not true. All identity permission verifications can be bypassed or spoofed by code with an adequate set of CAS permissions (which are, of course, granted by full trust), so SNIP use alone is not a strong protection against calls from "foreign" code. This certainly doesn't make your recommendation to use SNIP (or other identity permissions) any less relevant, but it simply doesn't offer the level of protection that you suggest. In addition, if plans discussed in the MSDN feeback centre for version 2 of the .NET Framework make it to production, fully trusted code will pass all identity permission verifications, thereby making even the "accidentally" part of your statement incorrect in future versions.

The second issue is a little less obvious but, since it's also one of the more glaring omissions in the documentation and samples you analyzed, it might be worth a bit of discussion. Basically, when examining the authentication-authorization process for web applications, you mention the use of IPrincipal implementations without addressing the potential for substitution of the principal object (e.g.: http://msdn.microsoft.com/library/en-us/cpguide/html/cpconreplacingprincipalobject.asp). Since you do cover other concerns related to shared hosting with potentially highly privileged code, this one is probably worth at least a bit of consideration too.

I thought your article on MSDN was good, and well overdue.

Why MS people are allowed the ability to disclaim any samples with 'I was lazy and took short cuts so this sample is of course useless for any real-world application' is beyond me. It saves them 5 minutes and wastes the rest of us days and days.

The fact that it's like that seems to highlight the fact that none of the security techniques are, to me, entirely satisfactory.

In our team we've asked various MS people the same basic question and got back different, less than satisfactory answers. The question: I don't want ASP.Net (pool identity) allowed direct access to SQL. I don't like the idea of connection strings in files or registry (encrypted or no). I don't want to host .Net components in COM+ purely to swicth identity. Whazt do I do?

Matt

^_^,Pretty Good!