IIS provides many security options for Web sites. However, IIS security mechanisms are very generic, in that the same mechanisms are used for all applications. Moreover, IIS security options — for example, using Windows Integrated security — might not always be convenient for your application. (For intranet applications, on the other hand, you might want to use Windows Integrated security for simplicity.)
Therefore, in order to provide access to specific portions of your application, you can use ASP.NET security. ASP.NET security works in conjunction with IIS security but extends it so that you can customize features, such as how to get user credentials.
IIS receives requests first from clients and performs any security checks that have been established for your application using IIS management tools. For example, if the application has been configured in IIS to allow anonymous access, IIS performs no credentials check. After performing this initial check of authentication, IIS sends the request to ASP.NET, which can perform a second level of checking. ASP.NET permite especificar restrições de acesso em seu aplicativo usando uma variedade de critérios: Você pode restringir o acesso a páginas específicas ou para usuários específicos e assim por diante.
A tabela a seguir descreve os métodos de autenticação que são suportados pelo ASP.NET. Várias dessas sobreposições com autenticaçãodo IIS. For details, see Autenticação do ASP.NET.
For applications where unknown users will be making requests (typically, public Web applications). Overlaps with IIS.
Basic and Digest authentication
(IIS Security Option) In this scenario, users without credentials are prompted to supply a user name and password.
Windows Integrated Security (also known as NTLM security)
(IIS Security Option) 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.
(IIS Security Option) In this scenario, the client has a certificate — a digital identification — that has been obtained from a third-party source. The identity mapped to the client certificate is passed to ASP.NET.
(IIS Security Option) The Kerberos authentication protocol defines the interactions between a client and a network Authentication Service known as a Key Distribution Center (KDC). Windows 2000 and 2003 implement a KDC as the authentication service on each domain controller.
(ASP.NET Security Option) Integrates with the previously listed IIS security options. ASP.NET takes the security token created by IIS and makes it available as a WindowsPrincipal object set as the value of the User property of the current HttpContext.
(ASP.NET Security Option) If a user needs to be authenticated, ASP.NET redirects the request to a page that you specify. This page usually contains a form in which you get user name information. (For extra security, the form can be exchanged using HTTPS protocol.) When your application gets the form information, it can perform an application-specific check of the user's credentials. An important point is that the process of authentication is under your control (unlike that for IIS), which allows you to specify what the form looks like and how you choose to store user information.
If a user is successfully authenticated, ASP.NET issues an encrypted cookie containing a token identifying the user for subsequent access.
Forms authentication is the easiest choice for ASP.NET applications on the public internet because it gives you substantial control over how users are authenticated and it allows you to store authentication in a token on the browser.
For details about IIS security, see the access-control topics in the Windows Server TechCenter for IIS on the Microsoft TechNet Web site. Para obter detalhes sobre o ASP.NET autenticação, consulte Autenticação do ASP.NET.
For details about using Forms authentication with protocol transition and constrained delegation in a Windows Server 2003 domain environment, see Kerberos Protocol Transition and Constrained Delegation.
When your Web application runs, it requests resources from the Web server and, often, from other processes as well, such as a database. The ASP.NET process runs in a user context that determines how your application will request those resources. The ASP.NET process runs as a special local user named ASPNET (by default) on Windows 2000 and Windows XP Professional Edition, or it runs as the identity of the application pool for the ASP.NET application on Windows 2003 (by default, the local NETWORK SERVICE account). These accounts run with limited permissions. You can specify a different user context for the ASP.NET process, including the local SYSTEM account (which runs your application in administrator context) or a user whose credentials you explicitly provide, though this is not recommended.
In your ASP.NET application, you can specify that different users have authorized access to different resources. If your application is using Windows authentication, you can use Windows permissions to determine authorization to access specific files or folders on the server.
Alternatively, you can use URL-based authorization, in which authorization can be granted or denied according to different criteria:
Specific users, or identities, which are based on the credentials provided by the user.
Roles, which are entities defined to allow multiple users to share privileges based on a common role or function.
Verbs, which are the HTTP processes (such as GET and POST) for accessing portions of your application.
For example, you can specify that all users can get pages (perform the GET verb) from your application, but that only specific users can post pages to it. Similarly, you might specify that all users are allowed to GET pages but specific roles are denied the right to post.
You can grant URL authorization for the application as a whole or on a directory-by-directory basis. A typical use is to allow all users to view pages in a public directory, but to keep restricted pages in a different directory that is authorized only for specific users or roles.
By default, static files, such as images and style sheets, are not subject to ASP.NET authorization when they are served through IIS. You can use IIS security features to restrict access to static files if you do not want all users to be able to access the files. If you use the ASP.NET Development Server to test your ASP.NET application, you will see different behavior because static files are subject to ASP.NET authorization and will not be served to an anonymous user when anonymous access to those files is disabled. Alternatively, you can map static file name extensions in IIS to the ASP.NET ISAPI extension, in which case the ASP.NET authorization rules will apply.
For more information, see Autorização ASP.NET and Práticas de segurança básica para aplicativos da Web.