validation authentication authorization impersonation delegation…
Almost all of my Web 1.0 cash comes from building read-only web sites for large audiences and back-end, Intranet data management clients (a friendly but thin wrapper for a database). In both of these situations, security concerns are low because of the read-only situation that’s public facing and because of the huge 10.* sandbox for the private Intranet. So professional security words like “validation authentication authorization impersonation delegation” just appeared to me as a mass of stuff passing by… The time has come to upgrade me!
“Authentication & Authorization” at codesecurely.org is an article with all these words in it. And it helps me to organize these words into groups. For example:
In multi-tiered applications, developers must choose between two fundamentally different models: the trusted subsystem model or the impersonation / delegation model. The trusted subsystem model relies on the web or application tier to authenticate the end-user. Once this has been done, all connections to back end resources are performed using a common set of credentials. On the other hand with the impersonation / delegation model, user credentials flow through the system and hence the web or application server are required to impersonate the logged on user before attempting to access back end resources.
My previous entry, “ADAM and PowerShell,” introducing me ADAM, comes right into this writ to reinforce the assertion that ADAM can be used with ASP.NET to form a “trusted subsystem.”
The default, easy way out that dates back to classic ASP is using the impersonation/delegation model by disallowing anonymous access. My renewed interest in Microsoft tools, prompted me to dig deeper into this issue as suggested by “An ASP.NET Question (or Two).” This research leads to the following table of links (taken out of del.icio.us in order of appearance):
| “[Using Management Tools](http://quickstarts.asp.net/QuickStartv20/aspnet/doc/management/tools.aspx)” | “To install without updating all applications to use ASP.NET 2.0, use `aspnet_regiis -ir`.”
This is a reminder of how “register” ASP.NET 2.0 with IIS 6.0. When you don’t do these things for a while, you tend to forget. (Unless you write it down!) |
| “[Simple Web Browse](http://www.aejw.com/default.aspx?dev/simplewebbrowse)” | Truly out of necessity this script was rewritten for my needs. For example the external, Win32 calls to `LogonUser()` were put in a static class for reusability.
The rewriting process opened up this whole issue about impersonation and delegation. |
| “[Impersonate User Account To Access Network Resources](http://www.netomatix.com/ImpersonateUser.aspx)” | This article talks about impersonation and uses the phrase, “access resources across network machines,” but does not mention delegation. This is my assumption today: without delegation you can’t access resources *across* network machines. |
| “[How To Impersonate A User Given Her Token](http://www.pluralsight.com/wiki/default.aspx/Keith.GuideBook/HowToImpersonateAUserGivenHerToken.html)” | The Microsoft partners at pluralsight.com dig really deep into the internals of Window security. This article is just the surface of the pool…
In “What is Impersonation” here is the dire warning, “As you’ve seen, impersonation can be a very useful tool in the hands of an architect. Implementation pitfalls abound, however, so read on to make sure you don’t fall into one. First of all, impersonation puts your thread into a somewhat wacky state. You’ve got two identities, controlled by your process token and your thread token. In some cases, this can cause surprising behavior. For example, almost all my students are surprised when I tell them how process creation works.” Great! In “How To Deal With Unauthenticated Clients” it gets ‘better’: “Now, you might be wondering why I didn’t suggest that you simply call |
| “[ASP.NET Impersonation](http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconASPNETImpersonation.asp)” | Microsoft pinpoints but does clearly explain (to me) my major impersonation issue: “If an application is on a universal naming convention (UNC) share, ASP.NET will always impersonate the token provided to IIS to access that share unless a configured account is used. If an explicit configured account is provided, ASP.NET will use that account in preference to the IIS UNC token. Applications that do want per-request impersonation can simply be configured to impersonate the user making the request.”
What is the “IIS UNC token”? Knowing this may open the whole thing up for me. Tick tock. No. It didn’t here an answer from Steve Jansen: “This is the token used to access files located on a remote UNC fileshare. …It is set in the MMC snap-in property page Properties > Home Directory > Connect As > Network Security Credentials (only visible when ‘A share located on another computer’ is selected in Home Directory… [Generally], you should avoid using UNC file shares for web app files. It’s complicates security and adds a performance bottleneck. IMHO, best practice is to host the files locally unless you need a common, shared directory between multiple hosts in a web farm…” Steve’s situation is different from when IIS is running under impersonation and calls the This MSDN article also strongly suggests that only the identity declared in |
| “[Work With Relative Paths](http://www.aspnetpro.com/newsletterarticle/2003/11/asp200311kd_l/asp200311kd_l.asp)” | This article gets me way off the topic of security but thoughts flow… This quote is interesting: “one of the best kept and largely undocumented secrets in ASP.NET is the tilde character (`~`). The tilde is actually a shortcut notation for the `HttpRuntime.AppDomainAppVirtualPath` property…” |