As you already know, live ASP.NET websites use the IIS web hosting software. But when you begin building and testing web application, you rely on the built-in Visual Studio web server instead. This difference has two effects on website security:

In addition, there are some security settings that come into play only when you configure a deployed website. For example, you can use IIS Manager to switch on Secure Sockets Layer (SSL), an encryption standard that makes sure malicious hackers can't eavesdrop on the messages sent between the user and your web server. You can also configure the specific protocols that IIS uses for Windows authentication (in other words, the exact security standard that's used to transmit user information and log someone in).

This chapter explains how to apply security to a website during development. The concepts and details you'll learn will apply equally well to a deployed application. However, if you want to adjust your security configuration after you deploy your application or if you want to get more advanced with SSL and Windows authentication settings, it's worth learning about IIS Manager. Chapter 26 has all the details.

You define the type of security in the web.config file by using the <authentication> tag.

The following example configures the application to use forms authentication by using the <authentication> tag. It also sets several of the most important settings using a nested <forms> tag. Namely, it sets the name of the security cookie, the length of time it will be considered valid (in minutes), and the page that allows the user to log in.

<configuration>
    <system.web>
        <authentication mode="Forms">
            <forms name="MyAppCookie"
                   loginUrl="~/Login.aspx"
                   protection="All"
                   timeout="30" path="/" />
        </authentication>
        ...
    </system.web>
</configuration>

Table 19-1 describes these settings. They all supply default values, so you don't need to set them explicitly. For a complete list of supported attributes, consult the Visual Studio Help.

If you make these changes to an application's web.config file and request a page, you'll notice that nothing unusual happens, and the web page is served in the normal way. This is because even though you have enabled forms authentication for your application, you have not restricted anonymous users. In other words, you've chosen the system you want to use for authentication, but at the moment none of your pages needs authentication.

To control who can and can't access your website, you need to add access control rules to the <authorization> section of your web.config file. Here's an example that duplicates the default behavior:

<configuration>
    <system.web>
        <authentication mode="Forms">
            <forms loginUrl="~/Login.aspx" />
        </authentication>

        <authorization>
            <allow users="*" />
        </authorization>
        ...
    </system.web>
</configuration>

The asterisk (*) is a wildcard character that explicitly permits all users to use the application, even those who haven't been authenticated. But even if you don't include this line in your application's web.config file, this is still the behavior you'll see, because ASP.NET's default settings allow all users. (Technically, this behavior happens because there's an <allow users="*"> rule in the root web.config file. If you're curious, you can find this file a directory like c:WindowsMicrosoft.NETFramework[Version]Config, where [Version] is the version of ASP.NET that's installed, like v4.0.30319.)

To change this behavior, you need to explicitly add a more restrictive rule, as shown here:

<authorization>
    <deny users="?" />
</authorization>

The question mark (?) is a wildcard character that matches all anonymous users. By including this rule in your web.config file, you specify that anonymous users are not allowed. Every user must be authenticated, and every user request will require the security cookie. If you request a page in the application directory now, ASP.NET will detect that the request isn't authenticated. It will then redirect the request to the login page that's specified by the loginUrl attribute in the web.config file. (If you try this step right now, the redirection process will cause an error, unless you've already created the login page.)

Now consider what happens if you add more than one rule to the authorization section:

<authorization>
    <allow users="*" />
    <deny users="?" />
</authorization>

When evaluating rules, ASP.NET scans through the list from top to bottom and then continues with the settings in any .config file inherited from a parent directory, ending with the settings in the base machine.config file. As soon as it finds an applicable rule, it stops its search. Thus, in the previous case, it will determine that the rule <allow users="*"> applies to the current request and will not evaluate the second line. This means these rules will allow all users, including anonymous users.

But consider what happens if these two lines are reversed:

<authorization>
    <deny users="?" />
    <allow users="*" />
</authorization>

Now these rules will deny anonymous users (by matching the first rule) and allow all other users (by matching the second rule).

<!-- This web.config file is in a subfolder. -->
<configuration>
    <system.web>
        <authorization>
            <deny users="?" />
        </authorization>
    </system.web>
</configuration>

<configuration>
    <system.web>
        <authentication mode="Forms">
            <forms loginUrl="~/Login.aspx" />
        </authentication>

        <authorization>
            <allow users="*" />
        </authorization>
        ...
    </system.web>

    <location path="SecuredPage.aspx">
        <system.web>
            <authorization>
                <deny users="?" />
            </authorization>
        </system.web>
    </location>

    <location path="AnotherSecuredPage.aspx">
        <system.web>
            <authorization>
                <deny users="?" />
            </authorization>
        </system.web>

</location>
</configuration>

<authorization>
    <deny users="?" />
    <deny users="matthew,sarah" />
    <deny users="john" />
    <allow users="*" />
</authorization>

<authorization>
    <deny users="?" />
    <allow users="matthew,sarah" />
    <deny users="*" />
</authorization>

You have another way to set up your authentication and authorization rules. Rather than edit the web.config file by hand, you can use the WAT from inside Visual Studio. The WAT guides you through the process, although you'll find it's still important to understand what changes are actually being made to your web.config file. It's also often quicker to enter a list of authorization rules by hand rather than use the WAT.

To use the WAT for this type of configuration, select Website

Figure 19.2. The Security tab in the WAT

To set an application to use forms authentication, follow these steps:

Next, it's time to define the authorization rules. To do so, click the Create Access Rules link. (You can also change existing rules by clicking the Manage Access Rules link.) Using the slightly convoluted page shown in Figure 19-3, you have the ability to create a rule allowing or restricting specific users to the entire site or a specific page or subfolder. For example, the rule in Figure 19-3 will deny the user jenny from the entire site once you click OK to add it.

Figure 19.3. Adding an authorization rule

To manage multiple rules, you'll need to click the Manage Access Rules link. Now you'll have the chance to change the order of rules (and hence the priority, as described earlier), as shown in Figure 19-4. If you have a large number of rules to create, you may find it's easier to edit the web.config file by hand. You might just want to create one initial rule to make sure it's in the right place and then copy and paste your way to success.

Figure 19.4. Ordering authorization rules

The Security tab is a little overwhelming at first glance because it includes a few features you haven't been introduced to yet. For example, the Security tab also allows you to create and manage user records and roles, as long as you're willing to use the prebuilt database structure that ASP.NET requires. You'll learn more about these details, which are part of a broad feature called membership, in the next chapter. For now, you'll concentrate on the authentication and authorization process.

Once you've specified the authentication mode and the authorization rules, you need to build the actual login page, which is an ordinary .aspx page that requests information from the user and decides whether the user should be authenticated.

ASP.NET provides a special FormsAuthentication class in the System.Web.Security namespace, which provides shared methods that help manage the process. Table 19-2 describes the most important methods of this class.

A simple login page can put these methods to work with little code. To try it, begin by enabling forms authentication and denying anonymous users in the web.config, as described earlier:

<configuration>
    <system.web>
        <authentication mode="Forms">
            <forms loginUrl="~/Login.aspx" />
        </authentication>

        <authorization>
            <deny users="?" />
            <allow users="*" />

</authorization>
        ...
    </system.web>
</configuration>

Now, users will be redirected to a login page named Login.aspx that you need to create. Figure 19-5 shows an example of the simple login page that you might build.

Figure 19.5. A typical login page

When the user clicks the Login button, the page checks whether the user has typed in the password Secret and then uses the RedirectFromLoginPage() method to log the user in. Here's the complete page code:

Public Partial Class Login
    Inherits System.Web.UI.Page

    Protected Sub cmdLogin_Click(ByVal sender As Object, _
      ByVal e As System.EventArgs) Handles cmdLogin.Click
        If txtPassword.Text.ToLower() = "secret" Then
            FormsAuthentication.RedirectFromLoginPage(txtName.Text, False)
        Else
            lblStatus.Text = "Try again."
        End If
    End Sub

End Class

The RedirectFromLoginPage() method requires two parameters. The first sets the name of the user. The second is a Boolean variable that specifies whether you want to create a persistent cookie (one that stays on the user's hard drive for a longer period of time). However, in an effort to be more secure, ASP.NET no longer honors this property in the way it was originally designed. (You'll learn more about persistent cookies shortly, in the section named "Persistent Cookies.")

Obviously, the approach used in the login page isn't terribly secure—it simply checks that the user supplies a hard-coded password. In a real application, you'd probably check the user name and password against the information in a database and sign the user in only if the information matches exactly. You could write this code easily using the ADO.NET programming you learned in Part 4, although it requires a bit of tedious code. You'll consider more practical ways to accomplish this task in the next chapter.

You can test this code with the FormsSecurity website that's included with the downloadable code for this chapter. If you request the SecuredPage.aspx file, you'll be redirected to Login.aspx. After entering the correct password, you'll return to SecuredPage.aspx.

Retrieving the User's Identity

Once the user is logged in, you can retrieve the identity through the built-in User property, as shown here:

Protected Sub Page_Load(ByVal sender As Object, _
  ByVal e As System.EventArgs) Handles Me.Load

    lblMessage.Text = "You have reached the secured page, "
    lblMessage.Text &= User.Identity.Name + "."
End Sub

You don't need to place the code in the login page. Instead, you can use the User object to examine the current user's identity any time you need to do so.

Figure 19-6 shows the result of running this code.

Figure 19.6. Accessing a secured page

You can access the User object in your code because it's a property of the current Page object. The User object provides information about the currently logged-in user. It's fairly simple—in fact, User provides only one property and one method:

• The Identity property lets you retrieve the name of the logged-in user and the type of authentication that was used.

• The IsInRole() method lets you determine whether a user is a member of a given role (and thus should be given certain privileges). You'll use IsInRole() later in this chapter.

UNDERSTANDING IDENTITIES

The User object is standardized so that it can work with any type of authentication system. One consequence of this design is that the User.Identity property returns a different type of object depending on the type of authentication you're using.

For example, when using forms authentication, the identity object is an instance of the FormsIdentity class. When using Windows authentication, you get a WindowsIdentity object instead. And if the user isn't logged in at all, you get a GenericIdentity. (All these classes implement the IIdentity interface, which standardizes them.)

Most of the time, you don't need to worry about this sleight of hand. But occasionally you might want to cast the User.Identity property to the more specific type to get access to an extra piece of information. For example, the FormsIdentity object provides the security ticket (in a property named Ticket), which isn't available through the standard IIdentity interface. This ticket is an instance of the FormsAuthenticationTicket class, and it provides a few miscellaneous details, like the time the user logged in and when the ticket will expire. Similarly, the WindowsIdentity object provides additional information that relates to Windows accounts (such as whether the current user is using a guest account or a system account). You'll see an example of this technique later in this chapter in the "Windows Authentication" section.

Protected Sub cmdSignOut_Click(ByVal sender As Object, _
  ByVal e As System.EventArgs) Handles cmdSignOut.Click

    FormsAuthentication.SignOut()
    Response.Redirect("~/Login.aspx")
End Sub

' Perform the authentication.
If txtPassword.Text.ToLower() = "secret" Then
    If chkPersist.Checked Then
        ' Use a persistent cookie that lasts 20 days.
        ' The timeout must be specified as a number of minutes.
        Dim timeout As Integer
        timeout = CInt(TimeSpan.FromDays(20).TotalMinutes)

        ' Create an authentication ticket.
        Dim ticket As New FormsAuthenticationTicket(txtName.Text, _
          True, cookietimeout)

        ' Encrypt the ticket (so people can't steal it as it travels over
        ' the Internet).
        Dim encryptedTicket As String = FormsAuthentication.Encrypt(ticket)

        ' Create the cookie for the ticket, and put the ticket inside.
        Dim cookie As New HttpCookie(FormsAuthentication.FormsCookieName, _
          encryptedTicket)
        ' Give the cookie and the authentication ticket the same expiration.
        cookie.Expires = ticket.Expiration

        ' Attach the cookie to the current response. It will now travel back to
        ' the client, and then back to the web server with every new request.
        HttpContext.Current.Response.Cookies.Set(cookie)

        ' Send the user to the originally requested page.
        Dim requestedPage As String
        requestedPage = FormsAuthentication.GetRedirectUrl(txtName.text, False)
        Response.Redirect(requestedPage, True)
    Else
        ' Use the standard authentication method.

FormsAuthentication.RedirectFromLoginPage(txtName.Text, False)
    End If
End If

To use Windows authentication, you need to make sure the <authentication> element is set accordingly in your web.config file. Here's how:

<configuration>
    <system.web>
        <authentication mode="Windows" />

        <authorization>
          <deny users="?" />
        </authorization>

...
    </system.web>
</configuration>

At the moment, there's only one authorization rule, which uses the question mark to refuse all anonymous users. This step is critical for Windows authentication (as it is for forms authentication). Without this step, the user will never be forced to log in.

Ideally, you won't even see the login process take place. Instead, Internet Explorer will pass along the credentials of the current Windows user, which the web server uses automatically. The Visual Studio integrated web server always works this way. IIS also works this way, provided you've set up integrated Windows authentication (as described in Chapter 26) and the browser supports it.

You can also add <allow> and <deny> elements to specifically allow or restrict users from specific files or directories. Unlike with forms authentication, you need to specify the name of the server or domain where the account exists. For example, this rule allows the user account matthew, which is defined on the computer named WebServer:

<allow users="WebServermatthew" />

For a shortcut, you can use localhost (or just a period) to refer to an account on the current computer, as shown here:

<allow users=".matthew" />

You can also restrict certain types of users, provided their accounts are members of the same Windows group, by using the roles attribute:

<authorization>
    <deny users="?" />
    <allow roles=".SalesAdministrator,.SalesStaff" />
    <deny users=".matthew" />
</authorization>

In this example, all users who are members of the SalesAdministrator or SalesStaff groups will be automatically authorized to access ASP.NET pages in this directory. Requests from the user matthew will be denied, unless he is a member of the SalesAdministrator or SalesStaff group. Remember, ASP.NET examines rules in the order they appear and stops when it finds a match. Reversing these two authorization lines would ensure that the user matthew was always denied, regardless of group membership.

You can also examine a user's group membership programmatically in your code, as shown here.

Protected Sub Page_Load(ByVal sender As Object, _
  ByVal e As System.EventArgs) Handles Me.Load

    If User.IsInRole("MyDomainNameSalesAdministrators") Then
        ' Do nothing; the page should be accessed as normal because
        ' the user has administrator privileges.
    Else
        ' Don't allow this page. Instead, redirect to the home page.
        Response.Redirect("Default.aspx")
    End If
End Sub

In this example, the code checks for membership in a custom Windows group called SalesAdministrators. If you want to check whether a user is a member of one of the built-in groups, you don't need to specify a computer or domain name. Instead, you use this syntax:

If User.IsInRole("BUILTINAdministrators") Then
    ' (Code goes here.)
End If

For more information about the <allow> and <deny> rules and configuring individual files and directories, refer to the discussion in the "Authorization Rules" section earlier in this chapter.

Note that you have no way to retrieve a list of available groups on the web server (that would violate security), but you can find out the names of the default built-in Windows roles using the System.Security.Principal.WindowsBuiltInRole enumeration. Table 19-3 describes these roles. Not all will apply to ASP.NET use, although Administrator, Guest, and User probably will.

One of the nice features of Windows authentication is that no login page is required. Depending on the authentication protocol you're using (see Chapter 26 for the complete details), the login process may take place automatically or the browser may show a login dialog box. Either way, you don't need to perform any additional work.

You can retrieve information about the currently logged-on user from the User object. As you learned earlier, the User object provides identity information through the User.Identity property. Depending on the type of authentication, a different identity object is used, and each identity object can provide customized information. To get some additional information about the identity of the user who has logged in with Windows authentication, you can convert the generic IIdentity object to a WindowsIdentity object (which is defined in the System.Security.Principal namespace).

The following is a sample test page that uses Windows authentication (see Figure 19-7). To use this code as written, you need to import the System.Security.Principal namespace (where the WindowsIdentity class is defined).

Public Partial Class SecuredPage
    Inherits System.Web.UI.Page

    Protected Sub Page_Load(ByVal sender As Object, _
      ByVal e As System.EventArgs) Handles Me.Load
        Dim displayText As New StringBuilder()
        displayText.Append("You have reached the secured page, ")
        displayText.Append(User.Identity.Name)

        Dim winIdentity As WindowsIdentity
        winIdentity = CType(User.Identity, WindowsIdentity)

        displayText.Append(".<br /><br />Authentication Type: ")
        displayText.Append(winIdentity.AuthenticationType)
        displayText.Append("<br />Anonymous: ")
        displayText.Append(winIdentity.IsAnonymous)
        displayText.Append("<br />Authenticated: ")
        displayText.Append(winIdentity.IsAuthenticated)
        displayText.Append("<br />Guest: ")
        displayText.Append(winIdentity.IsGuest)
        displayText.Append("<br />System: ")
        displayText.Append(winIdentity.IsSystem)
        displayText.Append("<br />Administrator: ")
        displayText.Append(User.IsInRole("BUILTINAdministrators"))

        lblMessage.Text = displayText.ToString()
    End Sub

End Class

Figure 19.7. Retrieving Windows authentication information