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

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

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

applica-tion resides and the client machine In a Windows-based authenticaapplica-tion 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 onto 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

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

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’sweb.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 yourweb.configfile

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, theweb.configfile 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 theweb.configfile 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>

<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="*" />

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 usingusers,roles, orverbsattributes 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 to 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

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 therolesattribute 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 theverbattribute

in the<allow>and<deny>elements

<deny verbs="GET, DEBUG" />

In this example, requests that come in using the HTTP GET or HTTP DEBUG protocols are denied access

to the site Possible values for theverbsattribute includePOST,GET,HEAD, andDEBUG

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

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 on

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 authenauthen-tication uses an

algorithm to encrypt the client’s credentials before they are sent to the application server

To use Digest authentication, 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

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’sweb.configfile, as illustrated in

Listing 21-3

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 theweb.configfile First, using the<authorization>element

described earlier, you are denying access to the application to all anonymous users Only authenticated users are allowed to 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 themodeattribute is set toFormsto employ forms-based authentication for your Web appli-cation The next attribute specified isloginUrl, which points to the page that contains the application’s login form In this example,Login.aspxis specified as a value If the end user trying to access the appli-cation is not authenticated, his request is redirected toLogin.aspxso 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 ispath It simply 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

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 isLogin.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 theEncryptionsetting Data val-idation is performed, but the cookie is not encrypted

to use/, which is the default setting