|
Drill Down on Authentication (Continued)
If the ticket is present, the module automatically creates the security context by initializing the HttpContext.Current.User property with a default instance of GenericPrincipal, which contains a FormsIdentity instance with the name of the currently logged-in user. Basically, you don't work with the module directly. Your interface to the module consists of the classes that comprise the System.Web.Security namespace (see Table 1). For most cases, you use the FormsAuthentication class and the FormsIdentity class, which represents a successfully authenticated user in your application.
You now have the background you need to use forms authentication successfully. The next step is to implement forms authentication in an application. Forms authentication consists of three basic steps. First, configure forms authentication in the web.config file. Second, configure IIS to allow anonymous access to the virtual directory, and configure ASP.NET to restrict anonymous access to the Web application. Finally, create a custom login page that collects and validates a user name and password, and then interacts with the forms authentication infrastructure for creating the ticket. The remainder of the article walks you through how to implement these steps.
You have to configure forms authentication appropriately in your web.config file. Forms authentication works if you configure this section with the value Forms for the mode attribute:
<authentication mode="Forms">
<!-- Detailed configuration options -->
</authentication>
The <authentication /> configuration is limited to the top-level web.config file of your application. If the mode attribute is set to Forms, ASP.NET loads and activates the FormsAuthenticationModule, which does most of the work for you. The initial configuration basically uses default settings for forms authentication that are hard-coded into the ASP.NET runtime. You can override any default settings by adding settings to the <system.web> section of the machine.config file. You can override these default settings in your application by specifying additional settings in the <forms /> child tag of this section (see Table 2).
Credentials Store in web.config
You have your choice of where to store credentials for the users when using forms authentication. You can store them in a custom file or in a database; basically, you can store them anywhere you want if you provide the code for validating the user name and password entered by the user with the values stored in your credential store. The easiest place to store credentials is directly in the web.config file through the <credentials /> subelement of the <forms /> configuration tag:
<authentication mode="Forms">
<!-- Detailed configuration options -->
<forms name="MyCookieName"
loginUrl="MyLogin.aspx"
timeout="20">
<credentials passwordFormat="Clear">
<user name=
"Admin" password="(Admin1)"/>
<user name="Mario"
password="Szpuszta"/>
<user name="Matthew"
password="MacDonald"/>
</credentials>
</forms>
</authentication>
Note that using web.config as a credential store is possible for simple solutions with only a few users. In larger scenarios, you should use the Membership API. Also, you can hash password values for credentials stored in the web.config file. Hashing is nothing more than applying one-way encryption to the password. This means you encrypt the password in a way that it can't be decrypted anymore.
You don't need to restrict access to pages in order to use authentication. It's possible to use authentication purely for personalization, so that anonymous users view the same pages as authenticated users (but see slightly different, personalized content). However, to demonstrate the redirection functionality of forms authentication, it's useful to create an example that denies access to anonymous users. This forces ASP.NET to redirect anonymous users to the login page.
To keep the example simple, use the technique of denying access to all unauthenticated users. Do this using the <authorization> element of the web.config file to add a new authorization rule:
<configuration>
<system.web>
<!-- Other settings omitted. -->
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Back to top
|