Access Permissions for Web Applications
Like any applications, Web applications need access to various system resources, such as files or databases. These resources are usually protected by access levels granted to different users and groups.
In a Web application, it might not be the application user who is requesting access directly. Instead, the user communicates to the Web application using a browser, and the Web application then requests the resource. This indirect access can introduce an issue of access permission.
There are several strategies for managing access permissions in a Web application. The sections below provide an overview of each option. Links in the topic will point you to topics that contain more information.
Access through Windows Integrated Security
If your Web application runs in an intranet environment — if all users will be running Windows and are behind the same firewall — the application can access resources using Windows integrated security. In this strategy, all users are authenticated as soon as they log on to Windows. The authentication process generates a token containing information for that user. (The token does not contain the user's credentials, only a code indicating that the user has been authenticated.) The Web application can use the token when requesting a local resource. For example, a logged-in user requests a Web Forms page in Internet Explorer. The request is passed to Internet Information Services (IIS) and then to ASP.NET, which can use the user's authentication token to request access to a file on the server computer.
Windows integrated security is generally the most secure option for Web access permissions. If it is practical in your application, you should configure the application to use this option.
For details, see ASP.NET Authentication.
Anonymous Access Using the ASP.NET User Account
In most applications, users typically access Web applications anonymously — that is, they do not initially provide authentication credentials. In that case, the Web application has to assume (impersonate) some identity that it can use to request resources.
By default, when ASP.NET allows anonymous access, the application runs in the context of a special local (not domain) account. The user context depends on the operating system. In Windows 2000 and Windows XP, applications run under the account called ASPNET. In Windows Server 2003, the user context is called NETWORK SERVICE. These user accounts are created during the .NET Framework installation process with a unique, strong password, and are granted only limited permissions. The ASPNET or NETWORK SERVICE user can access only specific folders that are required to run a Web application, such as the \bin directory in which a Web application stores compiled files.
Note IIS has a similar mechanism for mapping anonymous users to a specific local or domain user. You can use the IIS facility to remap anonymous access for all files in your application, not just ASP.NET files (Web Forms pages and controls). For details, see Microsoft Internet Information Server Security Overview.
If your Web application requires access to other resources on the Web server computer, you can grant permissions to the ASPNET or NETWORK SERVICE user as needed. For example, if the application needs to write a file to a directory, you will need to explicitly grant write permissions to the ASPNET or NETWORK SERVICE account in that directory.
Alternatively, you can specify a different user identity for ASP.NET to use when requesting resources. You can specify a user name (a local or domain user) in whose name requests are made. For details, see ASP.NET Process Identity. For details, see <processModel> Element. Or you can specify that ASP.NET instead run in a system (administrator) context.
Caution Running ASP.NET applications in the system context allows them to run with administration permissions on the server. If users can take control of your application, they will then have free access to many critical resources on the server.
There are some resources that you cannot by default access using the default user context, because they require access to resources that need administrative-level privileges. For example, if your application needs to create a new event log category using methods in the System.Diagnostics namespace, it cannot do so if it is running in the context of the ASPNET or NETWORK SERVICE user. In that case, you need to either change the application context or make changes that will make the event log accessible to the ASP.NET user account.
Caution Setting the process identity to a specific user name in place of the ASPNET or NETWORK SERVICE user identity requires that you provide a user name and a password that are both stored in the machine.config file. Storing any credential information can represent a security threat, because if someone manages to get access to the machine.config or if they gain administrator privileges on the Web server computer, they might be able to read or change this private information. Make the machine.config file read-only for all but administrative users. For details about setting the username and password in the machine.config file, see <processModel> Element.
Access Using Provided Credentials
Your Web application can also request resources by providing credentials at run time. This is not possible to all resources, but can work for resources that accept a username and password, such as databases that accept a connection string.
Security Note Accessing SQL Server using a connection string (known as "mixed mode") is less secure than using Windows integrated security. If the Web server and SQL server are running on the same computer, you can easily and securely use Windows integrated security.
You can get the credentials from the user directly, using Basic, Digest, or Forms authentication. For example, your application might prompt the user to supply a username and password when the user wants to access a restricted part of your site. For details about authentication, see IIS Authentication and ASP.NET Authentication.
Security Note Prompting the user for a username and password in your application is a potential security threat. Credential information must be transferred from the browser to your server, and ordinary HTTP transfers are unencrypted. For best security when prompting users to provide credentials in your application, you should use secure sockets layer (SSL), which encrypts information before sending it from the browser to the server. For details, see Using Secure Sockets Layer.
After getting credentials from a user, you can pass them on when requesting the resource. For databases, you can usually plug the username and password into a connection string when opening a connection. For other resources, you can call a Windows API called LogonUser that establishes a user context for the information you provide and uses it to request access to a resource.
Sometimes it is more convenient to store credentials directly with your application. For example, it is possible to create a database connection string that hard-codes a user name and password into it. For details, see Accessing SQL Server with Explicit Credentials.
Security Note Hard-coding credentials into an application is generally not advised, because the information can be read, even if it has been compiled. Even if you do hard-code any user credential information into an application, you should never use a user name that would give a user anything but the most minimal access privileges to a resource.
If you do choose to store credentials as part of an application, you should make an attempt to protect them. One possibility is to use the Data Protection API (DPAPI). For details, see the technical article Windows Data Protection on MSDN Online (http://msdn.microsoft.com/library/de...asp?frame=true).
Accessing Remote Resources (Delegation)
Sometimes the resource required by your application is on a computer other than the Web server. This is recommended for some resources, such as a database. In that case, the application must make a request to the remote computer on behalf of the user. This process is called delegation.
As with any request for resources, a request to a remote computer must include appropriate credentials. If your application allows anonymous access, IIS and ASP.NET do not have the user's credentials and therefore cannot use them during delegation to access remote resources. In that case, you can:
- Get explicit user credentials by prompting for them. The application can then pass these on to the remote computer as needed. If you are working with a SQL Server, you can add the user credentials to a connection string. For an example, see Accessing SQL Server with Explicit Credentials.
- Change the user context of the Web application from the ASPNET or NETWORK SERVICE user to a specific domain user whose credentials can be passed to the remote computer. For an example, see Accessing SQL Server Using a Mapped Windows Domain User.
Note If you are running the browser and Web server on the same computer and you are logged on as a domain user, delegation to a remote computer is not a problem, since the IIS computer has your credentials. Although this is a common testing scenario, it is a very rare production scenario. If possible, always test access permissions by running the browser and Web server on separate computers.
