Configuring Authentication

   

---

Configure security for a Windows service, a serviced component, a .NET Remoting object, and an XML Web service: Configure authentication type. Authentication types include Windows authentication, Microsoft .NET Passport, custom authentication, and none.

To understand security in distributed applications, you must be knowledgeable about the closely intertwined subjects of authentication and authorization. Authentication refers to the process of obtaining credentials from a user and verifying her identity. After an identity has been authenticated, it can be authorized to use various resources.

ASP.NET provides you with flexible alternatives for authentication. Some, but not all, of these authentication methods also make sense in regular Windows applications. You can perform authentication yourself in code or delegate authentication to other authorities. Because it's the most comprehensive case, I'll consider authentication in the context of ASP.NET applications first and discuss other types of distributed applications later in the chapter.

No Authentication

The simplest form of authentication is no authentication at all. To enable an application to execute without authentication, you add this section to its configuration file:

 <authentication mode="None" /> 

Setting the mode to None tells ASP.NET that you don't care about user authentication. The natural consequence of this, of course, is that you can't base authorization on user identities because users are never authenticated.

NOTE

Configuration Files Each ASP.NET application has its own configuration file named web.config. In addition, there is a computerwide configuration file named machine.config. Sub-webs can have their own independent web.config file as well. Configuration files are XML files that can be dynamically updated at runtime. For more details on the ASP.NET configuration mechanism, refer to MCAD/MCSD Training Guide (70-305): Developing and Implementing Web Applications with Visual Basic .NET and Visual Studio .NET . Visit www.quepublishing.com or www.examcram.com for more information on this title.

IIS and ASP.NET Authentication

One thing that trips up some developers is that there are actually two separate authentication layers in an ASP.NET application. That's because all requests flow through IIS before they're handed to ASP.NET, and IIS can decide to deny access before the ASP.NET process even knows about the request. Here's a rundown on how the process works:

1. IIS first checks to make sure that the incoming request comes from an IP address that is allowed access to the domain. If not, the request is denied .

2. Next, IIS performs its own user authentication, if it's configured to do so. I'll talk more about IIS authentication later in the chapter. By default, IIS allows anonymous access, so requests are automatically authenticated.

3. If the request is passed to ASP.NET with an authenticated user, ASP.NET checks to see whether impersonation is enabled. If impersonation is enabled, ASP.NET acts as though it were the authenticated user. If not, ASP.NET acts with its own configured account.

4. Finally, the identity from step 3 is used to request resources from the operating system. If all the necessary resources can be obtained, the user's request is granted; otherwise , it is denied.

As you can see, several security authorities interact when the user requests a resource or a Web page. If things aren't behaving the way you think they should, it can be helpful to review this list and make sure that you've considered all the factors involved.

Authentication Providers

So, what happens when a request gets to ASP.NET? The answer depends on the site's configuration. The ASP.NET architecture delegates authentication to an authentication providera module whose job it is to verify credentials and provide authentication. ASP.NET ships with three authentication providers:

• The Windows authentication provider allows you to authenticate users based on their Windows accounts. This provider uses IIS to perform the actual authentication and then passes the authenticated identity to your code.

• The Passport authentication provider uses Microsoft's Passport service to authenticate users.

• The Forms authentication provider uses custom HTML forms to collect authentication information and allows you to use your own logic to authenticate users. Credentials are then stored in a cookie.

To select an authentication provider, you make an entry in the web.config file for the application. You can use one of these entries to select the corresponding built-in authentication provider:

 <authentication mode="Windows" /> <authentication mode="Passport" /> <authentication mode="Forms" /> 

You can also create your own custom authentication provider. This doesn't mean that you plug a new module in place of the supplied provider; it means that you write custom code to perform authentication and set the authentication mode for the application to None . For example, you might depend on an ISAPI filter to authenticate users at the level of incoming requests. In that case, you wouldn't want to use any of the .NET authentication providers.

Configuring IIS Authentication

If you decide to use Windows authentication within your applications, you'll need to consider how to configure IIS authentication. That's because the Windows identities are actually provided by IIS. IIS offers four different authentication methods:

• If you select anonymous authentication, IIS does not perform any authentication. Anyone is allowed access to the ASP.NET application.

• If you select basic authentication, users must provide a Windows username and password to connect. However, this information is sent across the network in clear text, making basic authentication dangerously insecure on the Internet.

• If you select digest authentication, users must still provide a Windows username and password to connect. However, the password is hashed (scrambled) before being sent across the network. Digest authentication requires that all users run Internet Explorer 5 or later and that Windows accounts are stored in Active Directory.

• If you select Windows integrated authentication, passwords never cross the network. Users must still have a Windows username and password, but either the Kerberos or challenge/response protocols are used to authenticate the user. Windows-integrated authentication requires that all users run Internet Explorer 3.01 or later.

Step By Step 11.4 gives you practice in setting authentication at the IIS level.

STEP BY STEP

11.4 Configuring IIS Authentication

1. Create a new Visual Basic ASP.NET application. Add some text to the default Web Form so that you can later verify that it displays properly.

2. Open the web.config file for the application and verify that the authentication mode is set to Windows.

3. In Windows, select Start, Programs, Administrative Tools, Internet Services Manager.

4. In Internet Services Manager, drill-down into the tree view until you find the node that corresponds to your Visual Basic ASP.NET application. This node will have the same name as the application and will be located beneath the Default Web Site node. Right-click the application node and select Properties.

5. In the Properties dialog box, click the Directory Security tab. Click the Edit button in the anonymous access and authentication methods section to open the Authentication Methods dialog box, shown in Figure 11.5.

   Figure 11.5. Editing IIS authentication methods.

   

6. Uncheck the Anonymous Access check box and the Integrated Windows Authentication check box.

7. Check the Basic Authentication check box. Click Yes and then click OK twice to save your changes.

8. In Visual Studio .NET, select Debug, Start Without Debugging to run the project. You'll see the Enter Network Password dialog box shown in Figure 11.6. Enter your username and password to see the start page for the application. To log on to a domain account, enter the username as DOMAIN\User .

   Figure 11.6. Logging on with basic authentication.

   

Passport Authentication

ASP.NET has built-in connections to Microsoft's Passport authentication service. If your users have signed up with Passport, and you configure the authentication mode of the application to be Passport authentication, all authentication duties are offloaded to the Passport servers.

Passport uses an encrypted cookie mechanism to indicate authenticated users. If users have already signed in to Passport when they visit your site, they'll be considered authenticated by ASP.NET. Otherwise, they'll be redirected to the Passport servers to log in.

To use Passport authentication, you'll need to download the Passport Software Development Kit (SDK) and install it on your server. The SDK can be found at http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/msdn-files/027/001/885/msdncompositedoc.xml.

You'll also need to license Passport authentication. Currently, the license fees are $10,000 per year plus a periodic $1,500 testing fee. You can get details on licensing Passport at http://www.microsoft.com/netservices/passport/.

Forms Authentication

Forms authentication provides you with a way to handle authentication using your own custom logic within an ASP.NET application. (Note that this is different from custom authentication using an ISAPI filter, which takes place before the request ever gets to ASP.NET.) With forms authentication, the logic of the application goes like this:

1. When a user requests a page from the application, ASP.NET checks for the presence of a special cookie. If the cookie is present, the request is processed .

2. If the cookie is not present, ASP.NET redirects the user to a Web Form that you provide.

3. You can carry out whatever authentication checks you like in your form. When the user is authenticated, you indicate this to ASP.NET, which creates the special cookie to handle subsequent requests.

Step By Step 11.5 demonstrates the use of forms authentication.

STEP BY STEP

11.5 Implementing Forms Authentication

1. In Windows, select Start, Programs, Administrative Tools, Internet Services Manager.

2. In Internet Services Manager, drill-down into the tree view until you find the node that corresponds to your Visual Basic ASP.NET application. This node will have the same name as the application and will be located beneath the Default Web Site node. Right-click the application node and select Properties.

3. In the Properties dialog box, click the Directory Security tab. Click the Edit button in the Anonymous Access and Authentication Methods section to open the Authentication Methods dialog box.

4. Check the Anonymous Access check box. This will cause IIS to pass all requests directly to ASP.NET for processing.

5. If you receive a security warning, click Yes, and then click OK twice to save your changes.

6. Add a new Web Form to your Visual Basic ASP.NET application. Name the new form frmLogin.aspx .

7. Place a Label control, two RadioButton controls ( rbYes and rbNo ), and a Button control with the ID of btnLogin on the form. Give the two RadioButton controls the same value for the GroupName property . Figure 11.7 shows a design for this form.

   Figure 11.7. Testing forms authentication.

   

8. Double-click the Button control to open the form's module. Add a reference at the top of the module:

    Imports System.Web.Security 

9. Add this code to handle the Button control's Click event:

    Private Sub btnLogin_Click(_  ByVal sender As System.Object, _  ByVal e As System.EventArgs) _  Handles btnLogin.Click     If rbYes.Checked Then         FormsAuthentication. _          RedirectFromLoginPage("Admin", False)     End If End Sub 

10. Edit the web.config file to replace both the authentication and authorization sections as follows , changing the name of the project in the authentication tag to match the name you used for the project:

     <authentication mode="Forms"> <forms loginUrl="frmLogin.aspx"  name="StepByStep11-4"  timeout="1" /> </authentication> <authorization>    <deny users="?" /> </authorization> 

11. Run the project. Instead of the start page of the application, your browser will display the custom login form. To proceed further, you'll need to select the Yes radio button and click the Log In button.

Of course, in a real application, you'd likely implement a more sophisticated authentication scheme than just making users select a radio button! But in forms-based authentication, you can use any login scheme you can code. You might, for example, store usernames and IP addresses in a database and only allow users who connect from their registered IP address. Or you might develop a Web service that allows authenticating users over the Internet.

Note the change to the authorization section of the configuration file in this example. By default, the authorization section contains an allow element:

 <allow users="*" /> 

With that authorization setting, ASP.NET allows all userseven unauthenticated usersaccess to application resources. The * wildcard matches any user. For this example, I changed this to a deny element:

 <deny users="?" /> 

The ? wildcard matches only unauthenticated users. The net effect is to allow authenticated users access to all resources, while denying unauthenticated users access to any resources.

The <forms> element contains the name of URL of the form to use for login authentication, the name of the cookie to use, and a timeout that controls how long a user can work with the application before being directed back to the login page (here set to the very low value of one minute for testing).

When the user is authenticated by the login page, the form calls the RedirectFromLoginPage method of the FormsAuthentication object. The two parameters to this method are the name of the authenticated user and a Boolean value that controls whether to save a permanent (cross-session) cookie. In this case the second parameter is False , so the cookie is stored in memory only for the length of the browser session.

Note that the login form doesn't contain any reference to the page on which the user will go after authenticating. The forms authentication provider automatically keeps track of the name of the page that the user was trying to access and sends her there when you call the RedirectFromLoginPage method.

---

Top