Impersonation is a security feature that enables an application to be executed with a pre-defined identity. Using trusted ASP.NET applications to run as SYSTEM, the IIS process runs with a Windows User Account/IIS Anonymous user identity. In this scenario, if the users need functional access that the Windows User Account/IIS Anonymous user identity credentials may not otherwise have access to, we can use impersonation to provide the access.
Most of the time we have a requirement to download documents or images by clicking a link or a button. Impersonation can enable the application to provide this functional access without compromising data integrity.
In our Proof of Concept, we will create an ASP.NET web application with impersonation and enabled users to download content from a cross-domain file server with no user specific access.
We will be using:
The user sends a request to download the content (document/images) from a local browser by clicking a link or button on a portlet. The request goes to the web server, which redirects the request to a controller web application (download application). The download application connects to the file server using impersonation and downloads the content. The download app then sends a response back to the web server, which relays the content back to the user’s browser.
Some notes on this process:
Impersonation is a powerful feature; when used with care, it can enable an application designer to design/architect a secure and easy to manage application. However, there are some pitfalls that need to be studied carefully.
With Impersonation, you will sometimes see surprising behavior because we are working with two identities controlled by our process token and thread token. For example, if Process A is trying to access the file server, but it needs Impersonation to achieve this, then a Process Token B is created with the impersonated user that runs as separate process to the Process A. So any changes to the file server will be done under impersonated user credentials.