Configuring Authentication -CodeIdol

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. Authorization refers to granting rights based on that identity.

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 element 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 Developing and Implementing Web Applications with Visual C# .NET and Visual Studio .NET Training Guide, Exam 70-315 (ISBN 0-7897-2822-2).

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. 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:

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.
Next, IIS performs its own user authentication, if it's configured to do so. I talk more about IIS authentication later in the chapter. By default, IIS allows anonymous access, so requests are automatically authenticated.
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.
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 provider—a module whose job it is to verify credentials and provide authentication. ASP.NET ships with three authentication providers:

The Windows authentication provider enables 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 <system.web> element 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 need to consider how to configure IIS authentication 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 be running Internet Explorer 5 or later and that Windows accounts be 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 be running 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

Add a new Visual C# ASP.NET application named StepByStep11_4 to the solution. Add some text to the default Web Form so that you can later verify that it displays properly.
Open the web.config file for the application and verify that the authentication mode is set to Windows.
In Windows, select Start, Programs, Administrative Tools, Internet Services Manager.
In Internet Services Manager, drill down into the tree view until you find the node that corresponds to your Visual C# ASP.NET application. This node has the same name as the application, and it is located beneath the Default Web Site node. Right-click the application node and select Properties.
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.

5. IIS offers four different authentication methods.
Uncheck the Anonymous Access check box and the Integrated Windows Authentication check box.
Set the project as the startup project.
Check the Basic Authentication check box. Click Yes and then click OK twice to save your changes.
In Visual Studio .NET, select Debug, Run Without Debugging to run the project. You should see the Enter Network Password dialog box shown in Figure. 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.

6. The Windows authentication provider allows you to authenticate users based on their Windows accounts.

Passport Authentication

The Microsoft .NET Passport is an online service (www.passport.net) that enables users to use a single email address and a password to sign in to any .NET Passport-participating Web site or service. Users can create a free Passport account by registering at any .NET Passport participating Web site or by using the Windows XP .NET Passport Registration Wizard.

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 need to download the Passport Software Development Kit (SDK) and install it on your server. The SDK can be found at msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/msdn-files/027/001/885/msdncompositedoc.xml.

You 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 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:

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.
If the cookie is not present, ASP.NET redirects the user to a Web form that you provide.
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

Add a new Visual C# ASP.NET application named StepByStep11_5 to the solution. Add some text to the default Web form so that you can later verify that it displays properly.
In Windows, select Start, Programs, Administrative Tools, Internet Services Manager.
In Internet Services Manager, drill down into the tree view until you find the node that corresponds to your Visual C# ASP.NET application. This node has the same name as the application, and is located beneath the Default Web Site node. Right-click the application node and select Properties.
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.
Check the Anonymous Access check box. This causes IIS to pass all requests directly to ASP.NET for processing.
If you receive a security warning, Click Yes and then click OK twice to save your changes.
Add a new Web form to the Visual C# ASP.NET application. Name the new form frmLogin.aspx.
Place a Label control, two RadioButton controls (rbYes and rbNo with GroupName LogIn), and a Button control (btnLogin) on the form. Figure shows a design for this form.

7. Forms authentication provides a way to handle authentication by using your own custom logic.
Switch to code view and add the following using directive:
```
using System.Web.Security;
```

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


private void btnLogin_Click(

    object sender, System.EventArgs e)

{

    if(rbYes.Checked)

        FormsAuthentication.RedirectFromLoginPage(

            "Admin", false);

}

Edit the web.config file to replace both the <authentication> and <authorization> elements as follows:


<authentication mode="Forms">

    <forms loginUrl="frmLogin.aspx"

     name="StepByStep11_5"

     timeout="1" />

</authentication>



<authorization>

    <deny users="?" />

</authorization>

Set the project as the startup project.
Run the solution. Instead of the start page of the application, your browser displays the custom login form. To proceed further, you need to select the Yes radio button and click the Login 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 allow only 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> element of the configuration file in this example. By default, the <authorization> element contains an <allow> element:


<allow users="*" />

With that authorization setting, ASP.NET allows all users—even unauthenticated users—access to application resources. The * wildcard matches any user. For Step-by-Step 11.5, 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 the URL of the form to use for login authentication, the name of the cookie to use, and a timeout attribute. The timeout attribute controls the period a user can work with the application before being directed back to the login page. (Step-by-Step 11.5 sets to the very low value of 1 minute for testing.)

When the user is authenticated, 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 Step-by-Step 11.5, the second parameter is false, so the cookie is stored in memory, and only for the length of the browser session.

Note that the login form doesn't contain any reference to the page where 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 him there when you call the RedirectFromLoginPage() method.

June 25, 2007, 1:44 a.m.posted by fractal

Configuring Authentication