The one area that many developers do not have good grasp at is how Authentication tokens from IIS 6.0 is passed to ASP.NET 2.0 and how these tokens can subsequently be used for Authorization in an ASP.NET 2.0 Web Application.
The one question that arises quite often is when I click on “Integrated Windows Authentication” in IIS 6.0 “Authentication tab” how does this information get passed to ASP.NET 2.0 and when it is passed to my Web Application how do I flow the client identity between different Services such as a Web Service or a database like SQL Server for example?
On a side note if you need this client identity to flow across multiple hops between all your application servers, then you will need to use Kerberos with delegation credentials. A good article on how to configure delegation credentials is located here. If you are using Windows Server 2003 then two new features were added known as constraint delegation and protocol transition. With protocol transition, you could use form authentication on an ASP.NET 2.0 Web Application--as not to flow the Windows Authentication tokens across the Internet. In your ASP.NET code you can have Windows 2003 literally newop a new Windows Identity by calling impersonate based upon a user identity and string passed into the construct of WindowsImpersonate class and then enable impersonation on this new Windows Identity. This is new extension to Kerberos and allows you to flow this token off the Web Server to other Application Servers on your Network. Now of course for this to work your Windows 2003 Web Server needs to be part of a Windows 2003 Domain. The next thing you should also do is to enable constraint delegation. This way when use protocol transition to newop a new Windows Identity you can constrain this new delegated token so it can only talk to this particular SQL Server and a particular App Server for example. Thus, not allowing it to delegated to all service in your network which significantly increases the attack service.
So what pieces of identity information does IIS knows about based upon the configuration setup in IIS 6.0?
While the first IIS 6.0 knows of is the OS thread identity. This is the worker process that has an identity associated with it and has been configured in the IIS 6.0 Application pool on the “Identity tab” --which by default is the Network Service Account.
The second piece of identity information that IIS knows about is based upon the settings you configure in the “Authentication Tab” under IIS 6.0 such as “Integrated Windows Authentication”. In this example, IIS 6.0 will make the identity of calling user available after receiving the information when the browser negotiates with IIS 6.0.
Ok, so how does this relate to ASP.NET 2.0 and how are these two identities get passed to your ASP.Net 2.0 Application?
IIS 6.0 makes these tokens available via ISAPI extension and part of the APS.Net 2.0 runtime is an ISAPI API. Therefore, by default when your application starts up the worker process is spun up. Now of the course IIS 6.0 and ASP.NET will know about the worker process which is commonly referred to as the OS thread identity (by default Network Service Account). When the worker process calls your ASP.NET 2.0 the ISAPI API contains an extension control block. This extension control block will store a security token a.k.a the Impersonation token from the “Authentication Tab” that you configured in IIS, so for example if you enabled Integrated Windows Authentication then the Windows Authentication token of the logged in user as negotiated between IE and IIS is now passed to your ASP.Net 2.0 application.
So to recap what do we see from inside the ASP.NET side of the house?
One thing is we know the OS thread transitions over to ASP.Net with an identity on it from the worker process. This token value is available to make integrated resource type of calls. For example, if in my connection string I used integration security with SQL Server then it is the OS thread identity that is making the call regardless of who is logged into the ASP.NET application or the Windows Identity that may have been passed via the extension control block.
When we talk about impersonation inside ASP.NET we are talking about taking the OS thread and switching the identity to some new set of security credentials. The most common one is "Client Impersonation" in which the <identity impersonate=”true”/> tag in the Web.config is set and behind the scene when the worker process starts up ASP.NET 2.0 runtimes calls the “Set Thread Token” API which takes the impersonation token stored in the extension control block and now swaps it on top of the OS thread. Now the OS thread will now be running under the identity of calling user.
The other option is “Application impersonation” in which the “Logon User API” is called and takes the username and password as specified in the <identity impersonate=”true” user=”someuser” password=”somepassword”/> tag of our web.config. Now the OS thread will run under these credentials within the APS.Net 2.0 Application. With Application Impersonation this allows you run multiple applications in an single Application pool under the same executable but you want each application to use different identities when making resource calls.
In both of these instances the OS thread identity has been changed.
So far our ASP.NET 2.0 application knows about OS thread and the impersonation token from IIS, however, we cannot forget about the ASP.NET user principal which is derived from the HttpContext.User or Thread.Current Principal. In most cases the ASP.NET user principal and OS threat are not the same identity, thus we can have three different identities inside your ASP.NET 2.0 Applications.
In a big nut shell this is how the identity as specified under the Application pool “Identity tab” can be used to make integrated security calls under a single context or how this identity be swapped out with “Client” or “Application” impersonation depending upon our applications requirements.
In part two of this blog I will talk more about the ASP.NET user principal inside ASP.NET 2.0 and what we can do with this information.