ASP.NET 2.0 All-In-One Desk Reference For Dummies

By Doug Lowe Ken Cox Jeff Cogswell

John Wiley & Sons

Copyright © 2006 Doug Lowe
All right reserved.

ISBN: 978-0-471-78598-9

Chapter One

Security: Using Login Controls

In This Chapter

  •   Understanding authentication and authorization

  •   Using the Security Administration tool

  •   Restricting access

  •   Handling logins and lost passwords

  •   Managing users and roles programmatically

    Most of us feel uneasy about implementing Web site security, perhaps because it's hard to be 100% sure that you've got it right. Inadvertently allowing the Internet's bad guys to get in could be a Career Limiting Move (CLM) or worse. Therefore, it's comforting to put security in the hands of people who've done it before. Enter Microsoft's ASP.NET team. The team realized that so many of us were reinventing the security wheel (sometimes creating an oval wheel, out of whack) that it made sense to build membership and login capabilities directly into ASP.NET 2.0.

    Out of the box, we have all the tools we need to let people log in to the site, view what we allow them to view, and recover their lost passwords. Our goal in this chapter is to implement security while writing as little code as possible. We can do this by leveraging the standard authorization tools and functions in ASP.NET.


    As you work with membership terminology, note that roles refer to groups or categories of users. In addition, the terms users and members are interchangeable.

    Understanding Authentication and Authorization

    Authentication and authorization are easy to confuse. It might help to look at how these concepts work in a restaurant. In our scenario, areas such as the restaurant's entrance, dining room, and kitchen represent Web pages with different access levels.

    Anyone off the street can open the restaurant door and stand in the entrance. In that location, a visitor can look around while remaining completely anonymous because no one needs to know who he or she is. There's no need to grant any approval for him or her to be there.

    Our restaurant visitor, John Oliver, passes through the entrance. He intends to eat in the restaurant's dining room and has a reservation. He presents himself at the maitre d's stand at the dining room door. Up until now, Mr. Oliver has been anonymous and unchallenged. The "security" context changes at this point. To claim his reserved table Mr. Oliver must lose his anonymity. He identifies himself by telling the maitre d' his name. In this social context, Mr. Oliver's word is sufficient proof for the maitre d' to validate the person in front of him as Mr. Oliver. The maitre d' could have asked for identification, but that would drive Mr. Oliver away. It is, after all, just a restaurant. Mr. Oliver has been authenticated at the restaurant because the restaurant employee knows the person with whom he's dealing.

    Next, the maitre d' looks for Mr. Oliver's name on the evening's reservation list, which is like a database. The name appears on the list, confirming that the guest may sit at the table set aside for Mr. Oliver. You could say that Mr. Oliver has been authorized to enter the dining room and sit at a table.

    You can see that authentication and authorization are different issues. Authentication establishes who you are; authorization establishes what you can do.

    Authentication can also establish a pecking order for different groups of people. For example, although Mr. Oliver has been authenticated and authorized to enter the dining room, he has not been authorized to enter the VIP room unless Mr. Oliver's name appears on the VIP list. Nor can he enter the kitchen unless he is a member of the staff.

    Implementing Forms Authentication

    We're going to walk through the construction of a barebones Web site that uses forms authentication, the normal mode for a password-protected Internet Web site. Forms authentication requires the visitor to submit a valid username and password to gain access to protected pages. If the credentials are valid, the Web server issues a temporary cookie to the browser that acts as a token to allow entry into other protect pages without forcing the user to type the credentials each time.

    Before putting a shovel in the ground, it might help to understand the roles of the Web pages in our sample application.

    * default.aspx: This is the entrance to our Web site. As with the restaurant, anyone can browse here anonymously.

    * login.aspx: This is the page where visitors present their credentials for validation. In the restaurant example in the previous section, the customer identifies himself to the maitre d' to claim a reservation. Behind the scenes, we verify the username and password - just as the maitre d' checks his reservation list.

    * reserved.aspx: Browsers can only view the contents of this page if they have specific permission. In the restaurant scenario, this is the reserved table. Before a customer gets to this place, the maitre d' knows you and specifically grants you access.

    * register.aspx: This is where visitors to our site can request access to private pages. They must provide information about themselves before approval. The comparable step in the restaurant example is giving your name and phone number when making a reservation.

    * regular.aspx: We might allow anonymous browsers to view this page under certain conditions. In a restaurant, this would be an unreserved table in the dining room.

    Creating the Web site

    The example we are creating in this chapter uses Visual Web Developer Express (VWDE) to create a file-based Web site. We use the Express edition of SQL Server 2005 as the database engine. For maximum simplicity, we use the Visual Basic (VB) language and all the code (both HTML and server-side) goes into the .aspx. file. Let's get started!

    1. In Visual Web Developer Express, from the File menu, click New Web Site.

    2. In the New Web Site dialog box, under Templates, select ASP.NET Web Site.

    3. In the Location boxes, select File System and enter c:\resto as the location for the site.

    4. In the Language box, select Visual Basic.

    5. Click OK.

    As shown in Figure 1-1, VWDE creates a site that includes three files: Default.aspx, Default.aspx.vb, web.config and a folder, App_Data.

    6. Delete Default.aspx. The default page uses the code-behind model rather than the one-page model that we're using. You build the pages from scratch in the next section.

    Adding pages to the resto Web site

    Because the chapter is about security rather than design, I won't deal with creative aspects of pages here. Let's just add some plain ASP.NET pages to the site so we have something to configure. To do so:

    1. In Solution Explorer, select the root of the site and right-click it to bring up the context menu.

    2. Click Add New Item.

    The Add New Item dialog box opens, as shown in Figure 1-2.

    1. From the Visual Studio Installed Templates select Web Form.

    2. In the Name box, enter the name of the start page, default.aspx.

    3. In the Language box, select Visual Basic.

    4. Uncheck the check boxes for Place Code In Separate File and Select Master Page.

    5. Click Add.

    The new ASP.NET page appears in Solution Explorer.

    6. Repeat the preceding steps to add the following pages: login.aspx, reserved.aspx, register.aspx, and regular.aspx.

    When you're finished, Solution Explorer should look like Figure 1-3.

    That takes care of creating the raw pages. We add functionality to the pages in subsequent procedures. Before getting to that, however, we have to fix the site's directory structure. We need a directory for the exclusive use of logged in members. Although it's possible to secure individual pages in the root folder, ASP.NET's membership features are easiest to apply to whole directories rather than pages. To create the directory, follow these steps:

    1. In Solution Explorer, select the root of the site and right-click it to bring up the context menu.

    2. Select the New Folder item.

    3. Name the new folder members.

    4. Drag reserved.aspx from the root folder of the Web site and move it into the members folder.

    We encounter the members folder again when we set permissions. First, we have to set up ASP.NET's membership features.

    Implementing membership features

    Our Web site needs a database to store user information and credentials. When a person logs in, we look up the name and credentials before deciding what pages that person can visit.


    You need SQL Server 2005 Express on your workstation for these procedures. (If you haven't installed a copy, now's a good time to do so.)

    ASP.NET provides all you need for basic authentication and user management - with little or no code - thanks to the Web Site Administration tool. The hardest part is knowing where to click; the way to get a handle on that is to configure membership for our site. You should still have the resto project open. To configure membership for our site, follow these steps:

    1. In the IDE (that's the VWDE development environment), from the Website menu, click ASP.NET Configuration.

    The ASP.NET development server starts up and navigates to the Web Application Administration startup page, as shown in Figure 1-4.

    2. Click the Security tab. The page may take a few seconds to appear the first time.

    3. Click the link marked Use The Security Setup Wizard to configure security step by step.

    4. On the Welcome page, click Next.

    5. On the Select Access Method page, select the radio button for From The Internet and then click Next.

    6. On the Advanced provider settings page, click Next.

    7. On the Define Roles page, make sure the check box is cleared and then click Finish.

    The Web Site Administration Tool displays the Security tab. We deal with roles in section "Assigning users to roles," later in this chapter.


    Notice that we didn't complete all the wizard steps. That's not a problem because you can restart the wizard at any time to explore its capabilities. There are also other paths to the same functions, such as creating a user.

    Before moving on, let's investigate what the wizard has done for us. In your IDE, open Solution Explorer and click the Refresh button. Expand all the nodes and look under the App_Data folder - you should see a database file called ASPNETDB.MDF, as shown in Figure 1-5.

    So far we haven't written any code - but we've managed to create a database that includes numerous tables and stored procedures. You can investigate the database using the Database Explorer. Just go to View->Database Explorer. Expand the nodes, as shown in Figure 1-6. (We add data in the section, "Creating users," later in this chapter.)

    Creating users

    Our database is now ready for us to add some users, so let's add two user accounts. Once again, we turn to the Web Site Administration tool. To add users, follow these steps:

    1. Navigate to the Security tab (Website->ASP.NET Configuration and select the Security tab).

    2. In the table at the bottom of the page, locate the Users column and click the Create User hyperlink.

    The Create User page appears.

    3. Fill in the user's name, password, e-mail address, security question, and security answer, as shown in Figure 1-7.


    You can make up your own data, but you'll find it easier to follow along later with these values:

    Username: JohnOliver Password: OliverJoh! E-mail:

    Security Question: Your dog's name?

    Security Answer: Goldie


    ASP.NET requires that your passwords include a combination of upper-and lowercase letters and at least one non-alphanumeric character, such as a punctuation symbol.

    4. Click Create User.

    The confirmation message appears.

    5. Click Continue.

    6. Repeat the preceding steps and create another user with the following values:

    Username: JillAnon

    Password: AnonJill!


    Security Question: How high is Up?

    Security Answer: Very

    Creating access rules for the pages

    Recall that our goal is to allow anyone to browse the default page but permit only specific users to view pages in the members subdirectory. To do this, we have to create some access rules.

    Allowing anonymous users access to the root

    The first task is to ensure that everyone can reach the pages in the root of the Web, including the home page, default.aspx. To do so, follow these steps:

    1. Navigate to the Security tab (Website->ASP.NET Configuration and select the Security tab).

    2. In the table at the bottom of the page, locate the Access Rules column and click the Create Access Rules hyperlink.

    The Add New Access Rule page appears.

    3. In the left column, select the root folder (resto).

    4. In the right column, under Rule Applies To, select the Anonymous Users radio button.

    5. In the right column, under Permission, select the Allow radio button.

    The resulting access rule should look like Figure 1-8.

    Denying access for all users

    Our next step is to secure the members subdirectory by keeping everyone out. This exclusion includes anonymous users and users who are logged in. To secure the members subdirectory:

    1. In the Web Site Administration Tool, navigate to the Security tab (Website->ASP.NET Configuration and select the Security tab).

    2. Click Create access rules.

    The Add New Access Rule page appears.

    3. In the left column, expand the root folder (resto) and select the subdirectory called members.

    4. In the right column, under Rule Applies To, select the All Users radio button.

    We're creating a rule that applies to everyone.

    5. In the right column, under Permission, select the Deny radio button. The resulting access rule should look like Figure 1-9.

    6. Click OK. The Security page reappears. As of now, nobody can see pages in the members folder. We have to add one more rule to make the folder usable by that one special user, John Oliver.

    Allowing access to one user - John Oliver

    Of the two users we created previously, only John Oliver is allowed to access the members folder, including the reserved.aspx page. The following steps provide access to him after he logs in:

    1. Navigate to the Security tab (Website->ASP.NET Configuration and select the Security tab).

    2. Click Create Access Rules. 3. Select the subdirectory called members.

    4. Select the User radio button.

    5. Click the Search for Users link.

    The Search for Users page lists the users you added previously. Figure 1-10 shows part of the page with the usernames.

    6. Check the check box for JohnOliver and click OK.

    The browser returns to the Add New Access Rule page with the username JohnOliver in the text box, as shown in Figure 1-11.

    7. In the Permission area, select the Allow radio button.

    8. Click OK.


    Excerpted from ASP.NET 2.0 All-In-One Desk Reference For Dummies by Doug Lowe Ken Cox Jeff Cogswell Copyright © 2006 by Doug Lowe. Excerpted by permission.
    All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
    Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.