| By Derek Ferguson |
Article Rating: |
|
| August 11, 2003 02:22 PM EDT |
Reads: |
10,347 |
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!
Ulitzer content is offered under Creative Commons "Attribution Non-Commercial No Derivatives" License.
For any reuse or distribution, you must make clear to others the license terms of this work.
The best way to do this is with a link to this web page.
Any of the above conditions can be waived if you get written permission from Ulitzer, Inc., the copyright holder.
Nothing in this license impairs or restricts the author's moral rights.