IIS maintains security related configuration settings in the IIS metabase. However, ASP.NET maintains security (and other) configuration settings in XML configuration files. While this generally simplifies the deployment of your application from a security standpoint, the security model adopted by your application will necessitate the correct configuration of both the IIS metabase and your ASP.NET application via its configuration file (Web.config).
ASP.NET Authentication Providers and IIS Security
ASP.NET implements authentication using authentication providers, which are code modules that verify credentials and implement other security functionality such as cookie generation. ASP.NET supports the following three authentication providers:
Forms Authentication. Using this provider causes unauthenticated requests to be redirected to a specified HTML form using client side redirection. The user can then supply logon credentials, and post the form back to the server. If the application authenticates the request (using application-specific logic), ASP.NET issues a cookie that contains the credentials or a key for reacquiring the client identity. Subsequent requests are issued with the cookie in the request headers, which means that subsequent authentications are unnecessary.
Passport Authentication. This is a centralized authentication service provided by Microsoft that offers a single logon facility and membership services for participating sites. ASP.NET, in conjunction with the Microsoft® Passport software development kit (SDK), provides similar functionality as Forms Authentication to Passport users.
Windows Authentication. This provider utilizes the authentication capabilities of IIS. After IIS completes its authentication, ASP.NET uses the authenticated identity's token to authorize access.
To enable a specified authentication provider for an ASP.NET application, you must create an entry in the application's configuration file as follows:
// web.config file
In addition to authentication, ASP.NET provides an impersonation mechanism to establish the application thread's security token. Obtaining the correct token relies upon you configuring IIS authentication, ASP.NET authentication providers, and ASP.NET impersonation settings appropriately.
Authentication using Windows accounts
If you plan to authenticate users using accounts maintained by a Microsoft Windows NT® domain controller or within Microsoft Windows® 2000 Active Directory™, you should use IIS Authentication coupled with the Windows Provider for ASP.NET, as illustrated in Figure 2. By using this approach, you do not need to write any specific authentication code. When authentication happens using this method, ASP.NET constructs and attaches a Windows Principal object to the application context based on the authenticated user. As a result, the ASP.NET thread can run as the authenticated user and can obtain the user's group membership.
In some cases, you may want to bypass IIS authentication and implement a custom solution. This is also possible with ASP.NET. For example, you can write a custom ISAPI filter that checks the user's credentials against Active Directory and the creation of the Windows Principal object would be performed manually. There are other methods besides this one that will work, but they all require more code than using the .NET provider directly.
Authentication using non-Windows accounts
If you are planning to authenticate users at the application level, and the users do not have Windows accounts, you will typically configure IIS to use Anonymous authentication. In this configuration, consider the following .NET authentication modules:
None: Use when you are not authenticating users at all, or developing custom authentication code.
Forms: Use when you want to provide users with a logon page.
Passport: Use when you are using Passport services.
Impersonation and delegation
With impersonation, ASP.NET applications can optionally execute with the identity of the client on whose behalf they're operating. Impersonation is usually performed for resource access control. You should carefully consider whether or not impersonation is required, as it consumes additional server resources. Delegation is a more powerful form of impersonation and allows remote resources to be accessed by the server process while acting as the client.
If impersonation is enabled, ASP.NET will receive the token to impersonate from IIS. You have more granular control of impersonation in a Web application when using ASP.NET in comparison to traditional Active Server Pages (ASP). This is controlled by specifying a value in the application's Web.config file.
You have the following three options when specifying the required impersonation setting:
Impersonation enabled. In this instance, ASP.NET will impersonate the token passed to it by IIS, which will either be an authenticated user or the anonymous Internet user account.
Impersonation enabled, with a specific impersonation identity specified. In this instance, ASP.NET will impersonate the token generated using the configured identity. In this case the client token, if applicable, is not used.
Impersonation is disabled. This is the default setting for backward compatibility with ASP. In this instance, the ASP.NET thread will run using the process token of the application worker process, which by default is the IIS system account, regardless of which combination of IIS and ASP.NET authentication have been used.
If the application resides on a UNC share, ASP.NET will always impersonate the IIS UNC token to access that share unless a configured account is used. If an explicitly configured account is provided, ASP.NET will use that account in preference to the IIS UNC token.
No comments:
Post a Comment