Professional ASP.NET 3.5 in C# and Visual Basic Part 105 pdf

Evjen c21.tex V2 - 01/28/2008 3:15pm Page 998
Chapter 21: Security
As you can see, a couple of methods are at your disposal for building an authentication/authorization
model for your ASP.NET applications. We start by examining the Windows mode of authentication.
Windows-Based Authentication
Windows-based authentication is handled between the Windows server where the ASP.NET a pplica-
tion resides and the client machine. In a Windows-based authentication model, the requests go directly
to IIS to provide the authentication process. This type of authentication is quite useful in an intranet
environment where you can let the server deal completely with the authentication process — especially
in environments where users are already logged onto a network. In this scenario, you simply grab and
utilize the credentials that are already in place for the authorization process.
IIS first takes the user’s credentials from the domain login. If this process fails, IIS displays a pop-up
dialog box so the user can enter or re-enter his login information. To set up your ASP.NET application to
work with Windows-based authentication, begin by creating some users and groups.
Creating Users
You use aspects of Windows-based authentication to allow specific users who have provided a domain
login to access your application or parts of your application. Because it can use this type of authentication,
ASP.NET makes it quite easy to work with applications that are deployed in an intranet environment.
If a user has logged o nto a local computer as a domain user, he will not need to be authenticated again
when accessing a network computer in that domain.
The following steps show you how to create a user. It is important to note that you must have sufficient
rights to be authorized to create users on a server. If you are authorized, the steps to create users are
as follows:
1. Within your Windows XP or Windows Server 2003 server, choose Start ➪ Control Panel
➪ Administrative Tools ➪ Computer Management. If you are using Windows Vista, choose
Start ➪ Control Panel ➪ System and Maintenance ➪ Administrative Tools ➪ Computer Man-
agement. Either one opens the Computer Management utility. It manages and controls
resources on the local Web server. You can accomplish many things using this utility, but the
focus here is on the creation of users.
2. Expand the System Tools node.
3. Expand the Local Users and Groups node.

4. Select the Users folder. You see something similar to the results shown in Figure 21-2.
5. Right-click the Users folder and select New User. The New User dialog appears, as shown in
Figure 21-3.
6. Give the user a name, password, and description stating that this is a test user. In this
example, the user is called Bubbles.
7. Clear the check box that requires the user to change his password at the next login.
8. Click the Create button. Your test user is created and presented in the Users folder of the
Computer Management utility, as shown in Figure 21-4.
Now create a page to work with this user.
998
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 999
Chapter 21: Security
Figure 21-2
Figure 21-3
Authenticating and Authorizing a User
Now create an application that enables the user to enter it. You work with the application’s
web.config
file to control which users are allowed to access the site and which users are not allowed.
Add the section presented in Listing 21-1 to your
web.config
file.
999
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1000
Chapter 21: Security
Figure 21-4
Listing 21-1: Denying all users through the web.config file
<
system.web
>
<

authentication mode="Windows" /
>
<
authorization
>
<
deny users="*" /
>
<
/authorization
>
<
/system.web
>
In this example, the
web.config
file is configuring the application to employ Windows-based authentica-
tion using the
<
authentication
> element’s mode attribute. In addition, the <
authorization
> element
is used to define specifics about the users or groups who are permitted access to the application. In this
case, the
<
deny
> element specifies that all users (even if they are authenticated) are denied access to the
application. Not permitting specific users with the
<

allow
> element does not make much sense, but for
this example, leave it as it is. The results are illustrated in Figure 21-5.
Any end user — authenticated or not — who tries to access the site sees a large ‘‘Access is denied’’
statement in his browser window, which is just what you want for those not allowed to access your
application!
In most instances, however, you want to allow at least some users to access your application. Use the
<
allow
> element in the
web.config
file to allow a specific user. Here is the syntax:
<
allow users="Domain
\
Username"/
>
Listing 21-2 shows how the user is permitted access.
Listing 21-2: Allowing a single user through the web.config file
<
system.web
>
<
authentication mode="Windows" /
>
<
authorization
>
1000
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1001

Chapter 21: Security
<
allow users="REUTERS-EVJEN
\
Bubbles"/
>
<
deny users="*"/
>
<
/authorization
>
<
/system.web
>
Figure 21-5
Even though all users (even authenticated ones) are denied access through the use of the
<
deny
>
element, the definitions defined in the <
allow
> element take precedence. In this example, a single
user —
Bubbles
— is allowed.
Now, if you are logged on to the client machine as the user Bubbles and run the page in the browser, you
get access to the application.
Looking Closely at the
<

allow
>
and
<
deny
>
Nodes
The <
allow
> and <
deny
> nodes enable you to work not only with specific users, but also with groups.
The elements support the attributes defined in the following table.
Attribute Description
Users
Enables you to specify users by their domain and/or name.
Roles
Enables you to specify access groups that are allowed or denied access.
Verbs
Enables you to specify the HTTP transmission method that is allowed or denied access.
When using any of these attributes, you can specify all users with the use of the asterisk (
*
):
<
allow roles="*" /
>
1001
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1002
Chapter 21: Security
In this example, all roles are allowed access to the application. Another symbol you can use with these

attributes is the question mark (
?
), which represents all anonymous users. For example, if you want to
block all anonymous users from your application, use the following construction:
<
deny users="?" /
>
When using
users
,
roles
,or
verbs
attributes with the <
allow
> or <
deny
> elements, you can specify
multiple entries by separating the values with a comma. If you are going to allow more than one user,
you can either separate these users into different elements, as shown here:
<
allow users="MyDomain
\
User1" /
>
<
allow users="MyDomain
\
User2" /
>

or you can use the following:
<
allow users="MyDomain
\
User1, MyDomain
\
User2" /
>
Use the same construction when defining multiple roles and verbs.
Authenticating and Authorizing a Group
You can define groups of individuals allowed or denied access to your application or the application’s
resources. Your server can contain a number of different groups, each of which can have any number
of users belonging to it. It is also possible for a single user t o belong to multiple groups. Pull up the
Computer Management utility to access the list of the groups defined on the server you are working with.
Simply click the Groups folder in the Computer Management utility, and the list of groups is displayed,
as illustrated in Figure 21-6.
Figure 21-6
1002
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1003
Chapter 21: Security
Right-click in the Groups folder to select New Group. The New Group dialog displays (see Figure 21-7).
Figure 21-7
To create a group, give it a name and description; then click the Add button and select the users whom
you want to be a part of the group. After a group is created, you can allow it access to your application
like this:
<
allow roles="MyGroup"/
>
You can use the
roles

attribute in either the <
allow
> or <
deny
> element to work with a group that you
have created or with a specific group that already exists.
Authenticating and Authorizing an HTTP Transmission Method
In addition to authenticating and authorizing specific users or groups of users, you can also authorize or
deny requests that come via a specific HTTP transmission protocol. This is done using the
verb
attribute
in the
<
allow
> and <
deny
> elements.
<
deny verbs="GET, DEBUG" /
>
In this example, requests that come in using the HTTP GET or HTTP DEBUG p rotocols are denied access
to the site. Possible values for the
verbs
attribute include
POST
,
GET
,
HEAD
,and

DEBUG
.
1003
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1004
Chapter 21: Security
Integrated Windows Authentication
So far, you have been using the default Integrated Windows authentication mode for the authentication/
authorization process. This is fine if you are working with an intranet application and each of the clients is
using Windows, the only system that the authentication method supports. This system of authentication
also requires the client to be using Microsoft’s Internet Explorer, which might not always be possible.
Integrated Windows authentication was previously known as NTLM or Windows NT Challenge/
Response authentication. This authentication model has the client prove its identity by sending a hash
of its credentials to the server that is hosting the ASP.NET application. Along with Microsoft’s Active
Directory, a client can also use Kerberos if it is using Microsoft’s Internet Explorer 5 or higher.
Basic Authentication
Another option is to use Basic authentication, which also requires a username and password from the
client for authentication. The big plus about Basic authentication is that it is part of the HTTP specification
and therefore is supported by most browsers. The negative aspect of Basic authentication is that it passes
the username and password to the server as clear text, meaning that the username and password are
quite visible to prying eyes. For this reason, it is important to use Basic authentication along with SSL
(Secure Sockets Layer).
If you are using IIS 5 or 6, to implement Basic authentication for your application, you must pull up IIS
and open the Properties dialog for the Web site you are working with. Select the Directory Security tab
and click the Edit button in the Anonymous Access and Authentication Control box. The Authentication
Methods dialog box opens.
Uncheck the Integrated Windows Authentication check box at the bottom and check the Basic Authen-
tication check box above it (see Figure 21-8). When you do, you are warned that this method transmits
usernames and passwords as clear text.
Figure 21-8
1004

Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1005
Chapter 21: Security
End by clicking OK in the dialog. Now your application uses Basic authentication instead of Integrated
Windows authentication.
If you are using Windows Vista, it is not easy to find the option to enable Basic authentication. Instead,
you first have to enable IIS 7 to use Basic authentication by selecting Start ➪ Control Panel ➪ Programs
➪ Programs and Features ➪ Turn Windows features on or off. From the provided dialog box, nav-
igate to the Internet Information Services section and expand until you arrive at World Wide Web
Services ➪ Security. From here, check the Basic Authentication option and press OK to install. This option
is presented in Figure 21-9.
Figure 21-9
Once this option is installed, you can then return to the Internet Information Services (IIS) Manager
and select the Authentication option in the IIS section for the virtual directory you are focusing o n.
From there, highlight the Basic Authentication option and select Enable from the Actions pane. This is
illustrated in Figure 21-10.
Digest Authentication
Digest authentication is the final mode you explore in this chapter. The model alleviates the Basic authen-
tication problem of passing the client’s credentials as clear text. Instead, Digest authentication uses an
algorithm to encrypt the client’s credentials before they are sent to the application server.
To use Digest a uthentication, you are required to have a Windows domain controller. One of the main
issues that arises with Digest authentication is that it is not supported on all platforms and requires
1005
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1006
Chapter 21: Security
Figure 21-10
browsers that conform to the HTTP 1.1 specification. Digest authentication, however, not only works
well with firewalls, but it is also compatible with proxy servers.
You can select Digest authentication as the choice for your application in the same Authentication Meth-
ods dialog — simply select the Digest Authentication check box from the properties dialog if you are
using IIS 5 or 6. If you are using IIS 7, you need to install Digest Authentication just as you installed

Basic Authentication. Once installed, you will find this option and will be able to enable it from the
Authentication section within the IIS Manager.
Forms-Based Authentication
Forms-based authentication is a popular mode of authenticating users to access an entire application
or specific resources within an application. Using it enables you to put the login form directly in the
application so that the end user simply enters his username and password into an HTML form contained
within the browser itself. One negative aspect of forms-based authentication is that the usernames and
passwords are sent as clear text unless you are using SSL.
It is easy and relatively straightforward to implement forms-based authentication in your Web applica-
tion. To begin with, you make some modifications to your application’s
web.config
file, as illustrated in
Listing 21-3.
1006
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1007
Chapter 21: Security
Listing 21-3: Modifying the web.config file for forms-based authentication
<
system.web
>
<
authentication mode="Forms"
>
<
forms name="Wrox" loginUrl="Login.aspx" path="/" /
>
<
/authentication
>
<

authorization
>
<
deny users="?" /
>
<
/authorization
>
<
/system.web
>
You must apply this structure to the
web.config
file. First, using the <
authorization
> element
described earlier, you are denying access to the application to all anonymous users. Only authenticated
users are allowed t o access any page contained within the application.
If the requestor is not authenticated, what is defined in the
<
authentication
> element is put into action.
The value of the
mode
attribute is set to
Forms
to employ forms-based authentication for your Web appli-
cation. The next attribute specified is
loginUrl
, which points to the page that contains the application’s

login form. In this example,
Login.aspx
is specified as a value. If the end user trying to access the appli-
cation is not authenticated, his request is redirected to
Login.aspx
so that the user can be authenticated
and authorized to proceed. After valid credentials have been provided, the user is returned to the location
in the application where he originally made the request. The final attribute used here is
path
.Itsimply
specifies the location in which to save the cookie used to persist the authorized user’s access token. In
most cases, you want to leave the value as
/
. The following table describes each of the possible attributes
for the
<
forms
> element.
Attribute Description
name
This name is assigned to the cookie saved in order to remember the user from
request to request. The default value is
.ASPXAUTH
.
loginUrl
Specifies the URL to which the request is redirected for login if no valid
authentication cookie is found. The default value is
Login.aspx
.
protection

Specifies the amount of protection you want to apply to the authentication
cookie. The four available settings are:
❑
All
: The application uses both data validation and encryp-
tion to protect the cookie. This is the default setting.
❑
None
: Applies no encryption to the cookie.
❑
Encryption
: The cookie is encrypted but data valida-
tion is not performed on it. Cookies used in this man-
ner might be subject to plain text attacks.
❑
Validation
: The opposite of the
Encryption
setting. Data val-
idation is performed, but the cookie is not encrypted.
path
Specifies the path for cookies issued by the application. In most cases you want
to use
/
, which is the default setting.
1007