So pull up a chair, kick of your shoes, and read through our column all about common security issues when you access remote resources from ASP.NET applications. And remember, you can submit your ideas to us using the "ASK FOR IT" link included in every column we publish.
Common security issues when you access remote resources from ASP.NET applicationsIt is very common for developers to remotely access file shares, Web services, databases, or other resources from ASP.NET applications. This is typically a file server or database server separate from the Web server where the application is running. However, for this to work as expected, there are some very important security considerations to know about with regard to ASP.NET process identity, authentication, and permissions. We’ll explore some of these key concepts and possible resolutions. Which option will work best for a particular scenario will depend on your application architecture and security requirements.
The first and most important concept to consider is how the ASP.NET process and thread identity works. When the .NET Framework is installed on a Web server, it creates a low-privileged, local account named ASPNET, or on Microsoft Internet Information Services (IIS) 6.0, the NETWORK SERVICE account. By default, the ASP.NET worker process identity runs in the context of this account. Even more important is to understand that this is a local account. Let’s look at an example:
If we have a Web server (Server A) that runs an ASP.NET application that tries to access a file share on a second server (Server B), with default ASP.NET and IIS configurations, this will generate an
- Duplicate the default ASPNET account on the remote server. This involves creating an account with an identical user name and password. You must manually change the password for the ASPNET account in the Local Users and Groups on the Web server and also use this same password in the processModel password attribute of the Machine.config file.
- Change your ASP.NET process identity in the Machine.config file with:
<processModel userName=”domain\username” password=”pword” />
This must be a domain account so both the Web server and file server can authenticate the user. In IIS 5.x, this forces all ASP.NET applications on the Web server to run as the identity of the domain account specified. In IIS 6.0, the processModel section in the Machine.config file is ignored, and the ASP.NET process identity is controlled by the Application Pool identity. In IIS 6.0, you can create multiple AppPools with different identities so each application can run within its own separate process identity.
- Enable Basic authentication in IIS, disable Anonymous and Integrated authentication, and enable impersonation in ASP.NET. This will prompt the user for their credentials, authenticate them, and also pass the credentials as the WindowsIdentity to ASP.NET. Realize that Basic authentication sends user credentials in Base64 encoding, which can easily be decrypted. We recommend that Secure Sockets Layer (SSL) be used with this configuration.
- There are other impersonation options you can implement in your ASP.NET application. Depending on how you impersonate, ASP.NET will use either the IIS-authenticated user credentials or credentials you specify explicitly. With IIS integrated authentication, you can enable impersonation only in the Web.config file with:
<identity impersonate = “true” />
This will force the ASP.NET process identity to be the current authenticated user identity for the whole application. However, in a three-computer scenario, where you have the client browser, Web server, and separate file server, this presents what is referred to as a “double hop.” After a user has been authenticated from the client to the server, a primary security token is created, which is the first “hop.” This primary token can be passed only once because this is a design feature of NTLM security. When the Web server tries to authenticate against the file server again, it tries to pass that same security token which cannot be passed again, and creates the second “hop.” To work around this, you can enable impersonation and specify credentials in the Web.config file with:
<identity impersonate = “true” username=”Domain\UserName” password=”pword”/>
This will force the ASP.NET process identity to be whatever credentials you supplied for the “userName” and “password” attributes.
There are also other impersonation options, as described in following Microsoft Knowledge Base article:306158 How to implement impersonation in an ASP.NET applicationThe following link is to an ASP.NET identity matrix from the book “Building Secure Microsoft ASP.NET Applications.” This is very helpful in showing which identity is being used with different combinations of IIS authentication and ASP.NET impersonation:
- Enable ASP.NET for delegation as described in the following Knowledge Base article:810572 How to configure an ASP.NET application for a delegation scenario
- Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication
- 215383 How to configure IIS to support both the Kerberos protocol and the NTLM protocol for network authentication
- 317012 Process and request identity in ASP.NET
- 307626 ASP.NET configuration overview
- 264921 How IIS authenticates browser clients
- 316989 "Login failed" error message when you create a trusted data connection from ASP.NET to SQL Server
Ask For It form.
Article ID: 891031 - Last Review: 14 Jul 2008 - Revision: 1