The ASP.NET security model is made of a few distinct layers, the first of which is represented by the IIS context. When a client issues a web request, IIS picks it up and attempts to authenticate the caller. If the request comes from a nonrestricted IP address and the page can be viewed, IIS authenticates the caller using any of the predefined authentication mechanisms. Windows Authentication, Digest, and Basic are the three built-in authentication mechanisms supported by IIS. All of them return an identity token representing the caller. A fourth possibility is given by the anonymous access. In this case, the token is entitled to the configured anonymous user—usually IWAM_MACHINE.
If the URL requested is an ASP.NET resource, the control passes to the ASP.NET runtime. What happens next depends on how the ASP.NET security layer is configured. If ASP.NET is set up for Windows authentication, no additional steps are needed and ASP.NET just accepts any security token it receives from IIS. If ASP.NET is configured for Forms authentication, then the user is prompted for credentials using an application-specific HTML form. The user enters a name and password and attempts to login. Credentials are authenticated against a stored list of valid users. The application is free to choose the storage mechanism that best suits, including a SQL Server database or Active Directory services. Finally, if ASP.NET is configured for Passport authentication, then the user is redirected to a Passport web site and authenticated by the Passport service.
In all, ASP.NET supports four (not three) authentication models. The fourth possibility is None, meaning that ASP.NET does not attempt to perform its own authentication and completely relies on the results of the authentication already carried out by IIS. In this case, for example, anonymous users can connect and resources are accessed under the control of the ASP.NET current account. However, setting the ASP.NET authentication mode to the None option does not prevent the application from implementing its own personal authentication layer.
You choose the ASP.NET authentication mechanism using the <authentication> section in the web.config file. By default, the authentication mode is set to Windows. Child subdirectories inherit the authentication mode chosen for the application.
Authentication is only one facet of the security coin; the other face is authorization. Authentication refers to the application’s ability to identify the caller; authorization is the mechanism that verifies whether the authenticated user has the rights to access a given resource.
ASP.NET supports two types of authorization—through an Access Control List (ACL) on the resource and through a list of allowed or denied users and roles. If you use file authorization, the file system guarantees the security. If you use URL authorization, undesired users are automatically rejected. URL authorization, though, says nothing about the rights of the authenticated user to access a given resource. The application is responsible for the security of the resources.
When Forms authentication is selected, the ASP.NET application is free of implementing the authentication and authorization algorithms it likes. In this context, the use of Active Directory makes sense as a way to secure users and resources. Another typical scenario is when SQL Server is employed to store a list of users and the URL authorization is used to grant resources based on application-specific roles.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant based in Rome, Italy. Dino is a contributing editor to Windows Developer Network and MSDN Magazine, and the author of several books for Microsoft Press including Building Web Solutions with ASP.NET and ADO.NET and Applied XML Programming for .NET. Contact Dino at [email protected].
