Security Through Authentication

Regardless of what type of application you are creating in ASP.NET, the chances are very high that you will want to be able to identify the users who are connecting to your website. If you want to do something as simple as provide a personalized greeting or something as complex as identifying the user through some corporate single sign-on system, you will need to make use of some form of authentication. Authentication is the process of identifying who a particular user of your web application is by obtaining some set of credentials from the user and verifying those credentials against some authority. The authority can be a custom database, an Active Directory, or a single sign-on authority such as Microsoft Passport.

Authentication in ASP.NET works on the premise of providers. You choose which provider is providing authentication services for your application through a setting in the Web.config file.

You indicate the authentication provider within Web.config by setting the <authentication> element as follows:

<authentication mode="[Windows|Forms|Passport|None]"/> 

Three authentication providers come with ASP.NET: Windows, Forms, and Passport. If you choose "None" for your authentication provider, ASP.NET will not do anything whatsoever to identify the person requesting each page. In the next few sections of this chapter you will see how to use the three authentication providers.

Two main interfaces are used by all of the authentication providers: IPrincipal and IIdentity. These two interfaces allow for a standard method of identifying authenticated users.

When a user has been authenticated (even if that authentication failed), an ASP.NET page has access to the user credentials and other authentication through the web context. All pages have access to the web context through an instance of the HttpContext class, which you can access via the HttpContext.Current property. To obtain an IPrincipal representing the current user, you can make use of the HttpContext.Current.User property.

Windows Authentication

Windows authentication for ASP.NET is provided by the WindowsAuthenticationModule class (found in the System.Web.Security namespace). When a user is authenticated using Windows authentication, the provider will create an instance of the WindowsPrincipal class and make it available through the web context.

Windows authentication works by taking whatever Windows-based credentials (clear text, integrated, and so on) were supplied by Internet Information Server (IIS) and providing them to the ASP.NET application through the WindowsPrincipal and WindowsIdentity classes.

Because Windows authentication is the default authentication provider for ASP.NET, it is extremely easy to create a sample application to test it out. To do so, create a new C# website called Authentication. After you've done this, add the following lines of code to the Page_Load event handler of the default Web Form that comes with the application:

Response.Write(User.Identity.Name + "<BR>"); Response.Write("User is authenticated? " +      User.Identity.IsAuthenticated.ToString() + "<BR>"); Response.Write("Authentication Method: " +      User.Identity.AuthenticationType.ToString() + "<BR>"); 

The User object is made available to all ASP.NET web pages. If you are writing a server control or a user control, you can access the User object by using Page.User or HttpContext.Current.User. Figure 28.1 shows the output of this page when run under Windows authentication. Obviously the name of the user will change, but everything else should look very similar in your own development environment.

Figure 28.1. The output of a page displaying Windows authentication information.

Passport Authentication

Passport authentication is handled by the Passport authentication provider. Passport is a centralized authentication service provided by Microsoft. Your application benefits in that users can reuse the same Passport on any number of sites while still maintaining their own privacy. Your application, by making use of Passport, can skip a lot of the process usually involved in creating an authentication scheme. If you are developing on Windows Server 2003, you already have all the tools you need in order to work with Passport authentication. If you are not using Windows Server 2003, you will need to download the Passport SDK. For information on the Passport SDK and how to support Passport authentication on your website, go to http://www.passport.com/business. In order to see the documentation you will have to have a Passport of your own.

Much like Forms authentication (covered in the next section), Passport authentication works with cookies. When a user opens a browser to a Passport-secured website, the client's cookies are examined for a valid Passport authentication ticket. If it is found, the user is seamlessly delivered to the secured resource. If no such ticket is found, the user is redirected to the Passport authentication page hosted by Microsoft. After authentication takes place, the user is then redirected to the original secured resource. Because the user now has a valid Passport authentication ticket, the client is then given access to the protected resource.

The PassportAuthenticationModule detects the presence of a valid Passport and then creates a PassportIdentity instance, which then becomes available from within the User object as shown in the preceding samples.

The PassportIdentity class offers several additional methods and properties that are useful when creating a Passport-secured website. For a full reference on the PassportIdentity class, consult the MSDN documentation at http://msdn.microsoft.com and the Passport SDK, which can be found at http://www.passport.com/business and is included with Windows Server 2003.

Forms Authentication

Forms authentication is the most commonly used means of authentication for public-facing websites. The reason for this is that there are often concerns with securing a website with Windows authentication that must be accessible to users who don't belong to a domain and to users accessing the site across any number of router configurations, as well as a need for protection of credentials.

As mentioned in the Passport section, Forms authentication is cookie-based. This means that when a user has authenticated to a website, that fact is stored in a cookie on the user's machine. If the website fails to find an authentication cookie, the user is redirected to a login page where they can supply their credentials (or in some cases they can register a new account).

Forms authentication has several options that can be configured through the Web.config file. The options for the <forms> element in the Web.config file are shown in the following code:

<authentication mode="Forms">    <forms name="name"         cookieless=UseCookie|UseUri|AutoDetect|UseDeviceProfile         defaultUrl=[URL]    domain=domain name        loginUrl="url"    protection="All|None|Encryption|Validation"    timeout="30"    path="/"        requireSSL="true|false"        slidingExpiration="true|false">    <credentials passwordFormat="Clear|SHA1|MD5">      <user name="username" password="password"/>    </credentials>    </forms> </authentication> 

The following is a quick summary of some of the options shown in the preceding example:

• protection Indicates the protection used to secure the Forms authentication cookie

• timeout Indicates the amount of time (in minutes) that will elapse before a Forms authentication cookie will expire

• credentials Allows you to manually specify a list of users who can use your application directly in the web.config file

Also keep in mind that Visual Studio 2005 has a far more active and alert IntelliSense system than previous versionsyou will be able to see all of the options available to you while typing directly into the Web.config file.

The <forms> element only indicates how you are going to protect the pages on your website, not which locations you plan on protecting. To protect every page in your application except the login page, you can use a Web.config file that looks like this:

<?xml version="1.0"?> <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">     <appSettings/>     <connectionStrings/>     <location path="login.aspx">         <system.web>             <authorization>                 <allow users="*"/>             </authorization>         </system.web>     </location>     <system.web>         <compilation debug="true"/>         <authentication mode="Forms">             <forms loginUrl="login.aspx" name="MyApp" protection="All"/>         </authentication>         <authorization>             <deny users="?"/>         </authorization>     </system.web> </configuration> 

The authorization section indicates who has been granted access and who has been denied access. The wildcards ? and * indicate anonymous (unauthenticated) users and all users, respectively. You will see more about the authorization element later in the chapter in the section "Security Through Authorization."

When you use the FormsAuthentication class, several static methods are available to you for dealing with Forms authentication, including the following:

• RedirectFromLoginPage This method authenticates the user (saves their cookie) and redirects from the login page back to the original protected resource.

• RedirectToLoginPage This method sends the user to the login page, the URL of which is defined in Web.config.

• HashPasswordForStoringInConfigFile This method is a handy, quick way of storing a user's password in an encrypted hash.

• SetAuthCookie This method authenticates the user but performs no additional processing (such as redirection to a protected resource).

• SignOut This method will expire the current user's Forms authentication cookie.

• Authenticate If you are storing the user credentials in the Web.config, you can use this method to validate a username/password combination against those stored in the config file.

With a quick change to the preceding application and a call to FormsAuthentication.RedirectFromLoginPage, you can create a quick sample of Forms authentication. The three lines of code you used to display the WindowsIdentity details can also be used to show the same information from Forms authentication, as shown in Figure 28.2.

Figure 28.2. Forms authentication in action.

If you have experience with Forms authentication in previous versions of ASP.NET, you may think that this section is a little small. I am deliberately leaving out some of the more tedious programming tasks associated with authentication such as creating login pages, status controls, and so that on. Later in this chapter there is a section ("The ASP.NET Security Controls") covering a host of new UI controls that automate a great deal of the common tasks associated with authentication that work with any authentication provider, not just Forms.

User Management with Membership

Authentication requires that a set of credentials supplied by the user be validated against some previously stored set of credentials. The means by which you store the user credentials is completely up to you. You can store them in a SQL Server instance, you can store them in an XML file, or an Access database, or even the Web.config file.

Every web application that requires a user to log in must deal with the issue of storing the information about the website's members and their credentials. ASP.NET 2.0 provides a new API, the Membership API. This API abstracts the management of user storage and credentials in a standard way. As you will find out later in this chapter, there is also a set of standard controls that are fully compatible with the membership API.

The Membership API consists of the set of classes provided by ASP.NET for dealing with Membership that reside in the System.Web.Security.Membership. This API provides the following functionality:

• User management Create, edit, and delete users.

• Membership data management Maintain membership data, such as email addresses.

• Authentication The membership API is capable of validating supplied user credentials against the credentials contained in the membership store.

• Advanced password management Not only does the Membership API give you easy access to methods for changing user passwords, but through Membership, users can also retrieve and reset their own passwords.

The bottom line is that now the majority of the tasks you had to code manually each time you created an ASP.NET v1.x website are now bundled for you in a secure, easy-to-use library that is available to every ASP.NET 2.0 web application.

The first step to using Membership on any application is to make sure that the ASP.NET Membership schemas are installed properly. These schemas are installed in an instance of SQL Server, or your default SQL Express instance. If this was not already done for you at the time ASP.NET was installed, you can use the command-line utility aspnet_regsql.exe to do the job for you. You can find this tool in [drive:]\windows\Microsoft.NET\Framework\v[version].

The next thing you need to do is create a connection string for the Membership provider to use. This connection string will be stored in the new <connectionStrings> element in Web.config. If you installed the full version of SQL Server 2005, you will have a standard connection string. If you are using the Express version of SQL 2005, you will have a slightly different connection string. The following is the line of XML I used for my Membership connection string after installing the schemas into my copy of SQL Express:

[View full width]
<connectionStrings> <remove name="LocalSqlServer"/> <add name="LocalSqlServer"     connectionString="Data Source=.\SQLExpress;Integrated Security=True;User  Instance=True;AttachDBFilename=|DataDirectory|aspnetdb.mdf" /> </connectionStrings> 

Note that if you're using a full version of SQL Server, you should replace the .\SQLExpress instance name with the server name (and possible instance name) of your full installation of SQL Server. Next, you need to configure the Membership API from within the Web.config file. The following is a sample Membership provider configuration:

<membership defaultProvider="SqlProvider"    userIsOnlineTimeWindow="5">    <providers>    <clear/>      <add name="SqlProvider"           type="System.Web.Security.SqlMembershipProvider"           connectionStringName="LocalSqlServer"           applicationName="MembershipSample"           enablePasswordRetrieval="false"           enablePasswordReset="true"           requiresQuestionAndAnswer="true"           requiresUniqueEmail="true"           passwordFormat="Hashed" />      </providers> </membership> 

When you look at this configuration, the individual attributes of the <add> element correspond directly to some of the static properties of the Membership class.

Before we get into any serious Membership coding, let's take a look at some of the properties and methods of the Membership class, which are shown in Tables 28.1 and 28.2.

Table 28.1. System.Web.Security.Membership Properties

Property	Description
ApplicationName	The name of the application.
EnablePasswordReset	Indicates whether the user can request that their password be reset.
EnablePasswordRetrieval	Indicates whether the user can request to have their password given to them. Optionally requires the user to answer a security question.
MaxInvalidPasswordAttempts	The number of times a user can enter an incorrect password.
MinRequiredNonAlphaNumericCharacters	Password strength property indicating the minimum number of non-alphanumeric characters required for a "strong" password.
MinRequiredPasswordLength	Indicates the minimum size (in characters) of a strong password.
PasswordAttemptWindow	The number of minutes between the maximum password failures before the user is locked out.
PasswordStrengthRegular-Expression	A regular expression used to validate passwords. If the expression fails, the supplied password is too weak and will not be accepted.
Provider	Gets a reference to the default Membership provider.
Providers	The collection of available membership providers.
RequiresQuestionAndAnswer	Indicates whether the security question is required in order to retrieve or reset a password.
UserIsOnlineTimeWindow	The number of minutes since user's last activity that will elapse before the user is considered offline.

Table 28.2. System.Web.Security.Membership Methods

Method	Description
CreateUser	Creates a new user in the database specified in the provider configuration
DeleteUser	Removes a user from the Membership system
FindUsersByEmail	Searches through the user data, returning users with the given email address
FindUsersByName	Searches through the user data, returning users whose name matches the input
GeneratePassword	Creates a random password that is sufficiently strong to pass the strength validation test
GetAllUsers	Retrieve all of the users in the database
GetNumberOfUsersOnline	Gets the number of users currently using the application (within the configured inactivity period)
GetUser	Retrieves the membership information for a specific user
GetUserNameByEmail	Gets the user name for the user whose email address matches the input
UpdateUser	Commits changes made to the user to the Membership database
ValidateUser	Validates the supplied username and password against the Membership database

The impact of a standardized membership API is extremely significant. This allows for developers of membership-enabled ASP.NET applications to learn one simple API for managing users, and the only difference between one application and the other is the Web.config setting for the provider and connection string. I can't stress enough how incredibly useful the new provider model is for ASP.NET developers. Later in this chapter you will see how to create your own Membership provider.

To recap, the following are the steps to take in order to enable Membership in your ASP.NET application:

1.	Verify that the Membership schemas are installed in your database. You can do this with the aspnet_regsql.exe tool.
2.	Add your connection string to the Web.config file.
3.	Set up the <membership> element in Web.config.
4.	Begin using the Membership API and UI Controls.