ASP.NET Authentication Methods
| < Day Day Up > |
ASP.NET Authentication MethodsASP.NET provides its own authentication mechanism that comes into play after a request clears IIS (see Figure 6.1). ASP.NET authentication lets you add more flexibility and protection to your security implementation through four authentication and authorization options:
As with many other parameters in ASP.NET, you configure the authentication method by editing the Web.config application configuration file that resides in the application root folder. The code excerpt from this file included in Figure 6.6 displays the selected authentication options. Figure 6.6. Choosing ASP.NET Authentication Options<configuration> <system.web> <identity impersonate="true"/> <!-- This section sets the authentication policies of the application. Possible modes are "Windows", "Forms", "Passport" and "None" --> <authentication mode="Windows"/> <!-- This section sets the authorization policies of the application You can allow or deny access to application resources by user or role. Wildcards: "*" mean everyone, "?" means anonymous (unauthenticated) users. --> <authorization> <allow users="*"/> <!-- Allow all users --> <!-- <allow users="[comma separated list of users]" roles="[comma separated list of roles]"/> <deny users="[comma separated list of users]" roles="[comma separated list of roles]"/> --> </authorization> ... Windows AuthenticationWhen you select Windows authentication mode, ASP.NET relies on IIS to authenticate a request. IIS employs one of the authentication methods described earlier in this chapter and creates a Windows access token, which ASP.NET receives from IIS and uses later when user identity is requested . After IIS authenticates a user, ASP.NET executes in the context of the user. The portal site administrator can authorize user access to various objects and resources using the following two approaches:
Windows authentication works best in intranet portals or when the user base is not large and administrators can create a Windows account for each portal user. The code excerpt displayed in Figure 6.6 shows an application configured for Windows authentication. Note that identity impersonation has been turned on in this scenario. Identity impersonation was on by default in older versions of ASP; but in ASP.NET, it is not turned on by default. Using identity impersonation ensures that ASP.NET code will access the portal resources requested by a user executing under the context of the user's account. That allows the administrator to define resource usage rules based on a Windows user account. Imagine that your portal contains a document named Sensitive.doc. As a site administrator, you allow user Bob to read the document and deny any access to Alice. When Bob logs in to the portal using ASP.NET Windows authentication with identity impersonation turned on, ASP.NET code trying to read the Sensitive.doc will run as if it were Bob and will successfully retrieve the document. When Alice logs in, the code will execute with the privileges and access permissions associated with Alice's account and she will be denied read access to the document. If identity impersonation had been turned off, the code would have executed under the same account and the desired permission-granting granularity would have been lost. Passport AuthenticationPassport authentication uses the authentication service called Microsoft Passport. Microsoft keeps databases of user information and allows users to consume a centralized login service that authenticates the user and creates encrypted cookies containing user validation information on the client's machine. Microsoft Passport provides several services that can be used separately or within the same application, including:
Perhaps the most important advantage of using Passport authentication is that it supports a single pass-through login for multiple Passport-enabled sites or applications. This is a very elegant solution for a scenario in which you need to give a single login to a set of related applications or sites. With a Passport wallet, users can store their sensitive information in fewer locations. In addition, all web sites employing Passport services are required to comply with the standard privacy policy. The single sign-in process starts when a previously unauthenticated user tries to access a Passport-enabled site. Code on the protected page uses the Passport Manager object (in the .NET Framework, the PassportIdentity class) to redirect to a Microsoft Passport site where authentication occurs. Passport servers use the user's credentials along with the information about a Passport-enabled site during the authentication process. After this authentication process is finished, the user's browser is redirected back to the original site. Cookies are used to store user profile data and the Passport authentication ticket. Subsequent authentication requests would be based on the Passport cookies. To use passport authentication, site developers must write additional code using the Microsoft Passport Software Development Kit (SDK). Most of the .NET Passport functionality is exposed in code in the PassportIdentity class from the System.Web.Security namespace. The Passport SDK, which is available from Microsoft, must be installed on each server that uses Passport authentication. Passport service requires a subscription, but at present these subscriptions are free. Detailed discussion of the Passport SDK is beyond the scope of this chapter. To add Passport Single Sign-in to an ASP.NET application:
You can read more about Microsoft Passport at msdn.microsoft.com/library/default.asp?url=/downloads/list/websrvpass.asp. Passport integration is one of the new features of Windows Server 2003. By mapping Passport identity to an Active Directory identity, you can support an IIS-based authentication and authorization process without users having to log on to a Windows network. Forms AuthenticationThe Forms authentication method should be familiar to anyone who has ever built a custom authentication mechanism with pre-.NET versions of Active Server Pages (ASP). In those days, you would develop a simple HTML form to gather the username and password and then send it off to a middle- tier component for validation ”for example, by matching username and password against values stored in a database table. .NET Forms authentication uses a technology called HTTP client-side redirection. When an unauthenticated request comes in, it is redirected to a specified page where the user can enter his or her credentials. If these credentials are authenticated, an authentication token is created (typically a cookie). This token is reused during the same session whenever user identity information is requested because it is passed in the request header. The authentication cookie can also contain a list of roles for the authenticated user. It is important to keep in mind that Forms authentication does not provide any protection for user credentials when they are passed from an HTML form to the server. The best practice when using Forms authentication is to secure the channel used to pass credentials at all times by using SSL. Setting up Forms authentication does not require much coding. This form of authentication is configured in the application configuration file Web.config (see Figure 6.7). The code snippet in Figure 6.7 redirects all unauthorized requests to the Login.aspx page, which you can easily create by customizing the example page installed with Visual Studio.NET. Figure 6.7. Configuring Forms Authentication<authentication mode="forms"> <forms forms="401kApp" loginurl="/login.aspx" decryptionkey="l!#$$*13^"> <credentials passwordFormat=SHAl> <user name="Kim" password="9611E4F94EC4972D5A537EA28C69F89AD28E5B36"/> <user name="Jonn" password="BA7157A99DFE9DD70A94D89844A4B4993B10168F"/> </credentials> <forms> </authentication> Forms authentication is customarily used when security requirements are not extremely stringent. In this case, IIS authentication is often turned off (anonymous access is allowed), and user's credentials are requested by ASP.NET when it discovers that a valid session token is not present in the request header. The HTML form specified in the Forms section of the Web.config file is sent to the user's browser and is used to collect the user's credentials, which are then sent to ASP.NET for authentication. Figure 6.8 illustrates this process. Figure 6.8. Forms Authentication Process Flow No AuthenticationThis option is usually selected when no authentication is required on the ASP.NET side or when authentication is implemented completely outside of the built-in ASP.NET authentication method. The context under which the code will execute and the resources will be accessed depends on whether impersonation is turned on or off. If impersonation is enabled, the execution context is IUSR-<Machine Name>. If it is disabled, the Local System account will be used. ASP.NET is somewhat shielded from this issue because its worker process aspnet_wp is running by default as a special username ASPNET that is created automatically when you install the .NET Framework. |
| < Day Day Up > |
EAN: 2147483647
Pages: 164