Introduction to Web Application Security
Security is a critical part of your Web applications. Web applications by definition allow users access to a central resource — the Web server — and through it, to others such as database servers. By understanding and implementing proper security measures, you guard your own resources as well as provide a secure environment in which your users are comfortable working with your application.
This topic provides an overview of security for Web applications, describing what types of issues you need to think about when creating applications in Visual Studio. It also provides links to further information where you can learn more details about security features of Microsoft Internet Information Services (IIS) and of ASP.NET.
Authentication, Authorization, and Impersonation
Working with security requires that you understand these fundamental security concepts:
- Authentication confirms that users are who they say they are. For example, a user must provide a user name and password that are checked against an authority (a database, for example, or a Windows domain server).
- Authorization is the process of granting or denying access to resources for specific users.
These are concepts that are probably familiar from your use of Windows. In any sort of network, you log in (that is, you authenticate yourself). After doing that successfully, you can access specific files, folders, printers, and other resources — that is, you have authorization to get access to resources based on your login credentials. Windows provides a sophisticated security system that allows administrators to create user accounts and authorize those users to access folders, files, and so on.
There are security requirements in Web applications as well. However, the public nature of a Web application introduces some variations into this model. For example, in a public Web site, you would not expect every user to have to log into the computer or network where the Web server is running. To deal with this scenario, Web applications can impersonate users. Rather than requiring users to provide authentication credentials, a Web application might request a resource with some pre-established credentials.
Web Application Security in IIS and ASP.NET
Security for your Web application starts with the Web server (IIS). As a Windows-based service, IIS is fully integrated into Windows security. As with any other process, to access a file, IIS requires proper authentication. When users send a request from their browser to IIS, IIS must read the file from a Windows folder, and whatever Windows-defined authentication applies to the file applies to the IIS request as well. That is, to get access to a resource, IIS must provide proper credentials, the same as any other process.
When your Web applications run, they run under ASP.NET, which has its own security facilities. These come into play when your application requires access to resources. For example, if you want to read or write a file in your Web application, it is the ASP.NET security context that determines whether the request succeeds.
Not every user will have proper authentication to read files on a Windows server, however — particularly in Web applications available publicly on the Internet. IIS and ASP.NET therefore provide several mechanisms for establishing authentication. The descriptions below summarize these methods, necessarily leaving out many details about how the methods work. For details about IIS security, see the topics about access control in the IIS documentation on the Microsoft Web site (http://www.microsoft.com/windows2000/en/server/iis/). For details about ASP.NET security, see ASP.NET Web Application Security.
For applications where unknown users will be making requests (typically, public Web applications), IIS supports an "anonymous" user, namely, one who has no authentication credentials. In this scenario, the server on which IIS is running has an extra Windows user defined on it, with a user name of IUSR_<machinename>. This user account is typically defined with very restricted access rights.
When IIS gets a request from an unknown user, IIS turns around and makes the request to Windows using the <machinename>_anonymous user name as its credentials. That is, IIS impersonates the anonymous users for purposes of accessing the resource.
Basic and Digest Authentication
IIS also supports the Web-standard basic authentication model. In this scenario, users without credentials are prompted to supply a user name and password. These are returned to IIS where they become available to the application. Basic authentication provides a useful way to provide restricted access in a public Web application. However, because the user passes a user name and password to IIS as clear text, it is not highly secure.
Digest authentication is similar to basic authentication, but uses encryption to send user information to the server. However, this style of authentication requires a Windows domain controller.
Windows Integrated Security
If the user making the request has already been authenticated in a Windows-based network, IIS can pass the user's credentials through when requesting access to a resource. (The credentials do not include the user name and password, only an encrypted token indicating the user's security status.) This is a typical scenario in a corporate intranet, where users log into the network before using your application. However, integrated security is not practical in applications that must go through firewalls. Even within the same network, integrated security has limitations for accessing resources that are on remote computers. For details, see Access Permissions for Web Applications.
Finally, IIS supports the use of digital certificates and the secure sockets layer (SSL). In this scenario, either the server or the client has a certificate — a digital identification — that they have obtained from a third-party source. The certification is passed to your application with requests. It can be mapped to a Windows user account and granted appropriate permissions. This authentication has the advantage that, because each request or response is validated by the authority of the certificate, it lends itself to applications that require a trust relationship.
Access Permissions for Web Applications | Web Application Security at Design Time in Visual Studio | Web Application Security at Run Time | Accessing SQL Server from a Web Application | ASP.NET Impersonation | Security Model