On Being Someone Else

Sometimes I like to pretend that I'm someone else particularly when I'm writing an ASP.NET application. No, I'm not confessing any sort of deep psychological disturbance (although that is where extensive ASP.NET coding may eventually lead). Instead, I'm musing over the difficulty of achieving simple, reliable impersonation using .NET.

Those who have read the documentation but never actually tried it might believe this to be a relatively straightforward operation. Take, for example, Microsoft Knowledge Base Article 306158 (http://support.microsoft.com/default.aspx?scid=kb;[LN];306158), which offers the following options.

Impersonate the authenticated user via Web.config: This is fine, provided you don't want to allow any kind of limited access for users who can't authenticate. Put authentication on your Web site, and they will either get in or not there's no in-between. And if you use Basic authentication all of your usernames and passwords are going to be passing in clear text across the Internet!

Impersonate a specific user via Web.config: The problem with this is that I don't particularly want all of my application's users to have the same privileges. Also, I really don't want to put a plain text password in this configuration file! Making matters worse, on Windows 2000 the local ASPNET account has to have the "Act as a part of the operating system" privilege in order for this to work! This was fixed for Windows XP and beyond but is a real pain for anyone on an older operating system.

Impersonate the authenticating user via code: Again, you can't support users without valid credentials at all using this model, because they have to authenticate. However, it's better than the second option because I don't have to hard-code a username and password into a plain text configuration file.

Impersonate a specific user in code: This is an option I can live with, but it is fairly involved and definitely not 100% pure managed code. First, you have to call a native API to get a token for the user account you want to impersonate. Then, because the token doesn't support impersonation, you have to duplicate and modify it to support impersonation using another native API. Then, finally, you can begin impersonation using real, managed code.

Of course, even this assumes that under Windows 2000 you are running ASP.NET under an account that has the "Act as a part of the operating system" privilege.

Should such a basic operation really be this difficult? Wasn't part of the promise of .NET that all of the arcane native APIs of the past would finally be properly wrapped and accessible from a properly managed execution environment? Before I began my impersonation odyssey, I really thought that day was close at hand. Now, I'm not so sure.

Reliability
So, the topic for this month's journal is Reliability. And who would dare debate the importance of this? Whether you're designing a minor tape library system for a "mom-and-pop" video store or a critical guidance system for a mission to Mars, your employer expects your code to work and work well!

So, toward this end, we have assembled our usual stellar assortment of experts and gurus to guide you along your way. At the server, Doug Holland shows us how to increase the reliability of ASP.NET using reflection. Meanwhile, on the client, Amit Klien teaches us the most important principles of coding reliable, secure applications for .NET. And finally, you will find a product review of a tool from Parasoft called .TEST, which can help you make sure you are correctly applying the tips and techniques described elsewhere in this issue.

As always, feel free to contact me with all of your questions, concerns, and praise at derek@sys-con.com. I look forward to hearing from you!

About The Author
Derek Ferguson is editor-in-chief of .NET Developer's Journal and author of the book Mobile .NET (Apress). He is also chief technology evangelist for Expand Beyond Corporation (www.xb.com), a worldwide leader in mobile software for enterprise management. derek@sys-con.com