Lesson 2: Using Windows Authentication

Lesson 2: Using Windows Authentication

Windows authentication uses the security features integrated into the Windows NT and Windows XP operating systems to authenticate and authorize Web application users. The advantage of Windows authentication is that your Web application can use the exact same security scheme that applies to your corporate network user names, passwords, and permissions are the same for network resources and Web applications.

After this lesson, you will be able to

  • Activate Windows authentication in your Web application

  • Allow or deny access to your application based on the user s name or role in your organization

  • Identify users within your application once they have logged on

  • Use IIS settings to provide other forms of authentication

  • Run code under the identity of the Web application user

  • Run code under a specific identity

Estimated lesson time: 20 minutes

Enabling Windows Authentication

Windows authentication is the default authentication method when you create a new Web application project.

To see how Windows authentication works, follow these steps:

  1. Create a new Web application project. For a Microsoft Visual Basic .NET project, change the <authorization> element in the Web.config file to appear as follows. For a Microsoft Visual C# project, add the following <authorization> element:

     <authorization>  <deny users="?"  />  </authorization>

  2. Add the following HTML table definition to the project s startup Web form:

    <TABLE > <TR> <TD>Authenticated</TD> <TD><SPAN  runat="server"></SPAN></TD> </TR> <TR> <TD>User name</TD> <TD><SPAN  runat="server"></SPAN></TD> </TR> <TR> <TD>Authentication type</TD> <TD><SPAN  runat="server"></SPAN></TD> </TR> </TABLE>

  3. Switch the Web form to Design view, and add the following code to the startup Web form s code-behind module:

    Visual Basic .NET

    ' Add at module-level. Imports System.Web.Security Private Sub Page_Load(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load spnAuthenticated.InnerText = User.Identity.IsAuthenticated spnUserName.InnerText = User.Identity.Name spnAuthenticationType.InnerText = User.Identity.AuthenticationType End Sub

    Visual C#

    // Add at module-level. using System.Web.Security; private void Page_Load(object sender, System.EventArgs e) { spnAuthenticated.InnerText = User.Identity.IsAuthenticated.ToString(); spnUserName.InnerText = User.Identity.Name; spnAuthenticationType.InnerText = User.Identity.AuthenticationType; }

  4. Run the project.

When the project runs locally, ASP.NET will authenticate you using the name that you used to log on to Windows, as shown in Figure 8-6.

figure 8-6 windows authentication running locally

Figure 8-6. Windows authentication running locally

When you run the project remotely (as across the Internet), ASP.NET displays a dialog box in the browser to collect your user name and password, as shown in Figure 8-7.

figure 8-7 windows authentication running remotely

Figure 8-7. Windows authentication running remotely

If the user name and password you enter match those authorized for the network domain, ASP.NET authenticates you and authorizes you to use the application. If impersonation is enabled, the application executes using the permissions found in your user account. Otherwise, the application executes using the limited ASPNET user account.

When a user is authorized, ASP.NET issues an authorization certificate in the form of a cookie that persists for the duration of the user s session. The user s session ends when the browser closes or when the session times out.

Windows authentication works best in a domain-based network. Networks that use workgroups rather than domains have more limited use of network security features. Domain-based networks use a domain controller to identify and authorize network users, as shown in Figure 8-8.

figure 8-8 domain-based network authentication

Figure 8-8. Domain-based network authentication

One of the key advantages of Windows authentication is that users who are logged on to the network don t have to log on again to access the Web application. They are automatically authenticated. Another advantage is that corporate users can use their same network user names and passwords when accessing the Web site remotely from home or while on business trips.

Windows authentication also lets you establish another layer of security by permitting or prohibiting specific users or groups of users. Also, Windows authentication overlaps similar features found in IIS. The following sections describe these topics in more detail.

Allowing or Denying Access to Specific Users

When the application uses Windows authentication, ASP.NET checks the project s Web.config authorization list to see which network users are allowed to access the application. The asterisk (*) and question mark (?) characters have special meaning in the authorization list: the * character indicates all users; the ? character indicates unauthenticated users. For example, the following authorization list from Web.config requires all users to be authenticated:

<authorization> <deny users="?"  /> <!-- Deny unauthenticated users --> </authorization>

To restrict access to specific users, list their names separated by commas in an <allow> element. When ASP.NET checks the authorization list in Web.config, it accepts the first match that it finds. Be to sure to end the authorization list with a <deny> element to deny access to any nonapproved users, as shown here:

<authorization> <allow users="contoso\DeannaMeyer, contoso\MichaelEmanuel" /> <!-- Allow two users. --> <deny users="*"  /> <!-- Deny anyone else. --> </authorization>

This authorization list allows only two users access to the Web application. Everyone else is denied. In addition, Deanna Meyer and Michael Emanuel must have accounts on the contoso network domain.

Using Role-Based Authorization

Role-based authorization lets you identify groups of users to allow or deny based on their role in your organization. In Windows NT and Windows XP, roles map to names used to identify user groups. Windows defines several built-in groups, including Administrators, Users, and Guests. You can view, modify, or add groups using the Computer Management console, as shown in Figure 8-9.

figure 8-9 viewing groups

Figure 8-9. Viewing groups

To allow or deny access to certain groups of users, add the <roles> element to the authorization list in your Web application s Web.config file. For example, the following authorization list allows access only to users logged on to the contoso domain as system administrators:

<authorization> <allow roles="contoso\Administrators" /> <!-- Allow Administrators. --> <deny users="*"  /> <!-- Deny anyone else. --> </authorization>

Getting the User Identity

Once a user is authenticated and authorized, your application can get information about the user by using the User object s Identity property. The Identity property returns an object that includes the user name and role information, as shown in the following code:

Visual Basic .NET

Private Sub Page_Load(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load spnAuthenticated.InnerText = User.Identity.IsAuthenticated spnUserName.InnerText = User.Identity.Name spnAuthenticationType.InnerText = User.Identity.AuthenticationType End Sub

Visual C#

private void Page_Load(object sender, System.EventArgs e) { spnAuthenticated.InnerText = User.Identity.IsAuthenticated.ToString(); spnUserName.InnerText = User.Identity.Name; spnAuthenticationType.InnerText = User.Identity.AuthenticationType; }

In addition, the User object provides an IsInRole method to determine the role of the current user, as in the following example:

Visual Basic .NET

If User.IsInRole("Administrators") Then ' Do something End If

Visual C#

if(User.IsInRole("Administrators")) // Do something.

These methods and properties can be used in conjunction with the Global module s AuthorizeRequest event to customize the user authorization process. For example, you can use the AuthorizeRequest event to check user names against an external user file rather than use the list in Web.config.

Using IIS Settings with Windows Authentication

The authorization settings in Web.config overlap settings available in IIS. If authorization is set both in Web.config and in IIS, the IIS setting is evaluated first and then the setting in Web.config is evaluated. In general, this means that the most restrictive setting will be used.

To view authorization settings in IIS, follow these steps:

  1. In the IIS snap-in, right-click the Web application s folder, and select Properties. IIS displays the folder s Properties dialog box.

  2. Click the Directory Security tab, and then click Edit in the Anonymous Access And Authentication Control area. IIS displays the Authentication Methods dialog box, as shown in Figure 8-10.

    figure 8-10 iis authentication settings

    Figure 8-10. IIS authentication settings

The first group of settings in the dialog box controls anonymous access by unauthenticated users. Clearing the check box is the equivalent of specifying <deny users= ?"> in Web.config. Allowing IIS to control the password for the anonymous account is highly recommended, but this setting might need to be overridden if your application is deployed over multiple servers.

The check boxes in the second group of dialog box controls allows your application to use Basic or Digest authentication in addition to Windows authentication. Those authentication methods provide less security than Windows authentication, Forms, or Passport authentication and are implemented through IIS rather than ASP.NET.

As you can see in Figure 8-10, you can enable multiple authentication methods through IIS. If multiple methods are enabled, you can detect which method was used to authenticate a user in code by using the Identity object s AuthenticationType method, as shown here:

Visual Basic .NET

Response.Write(User.Identity.AuthenticationType)

Visual C#

Response.Write(User.Identity.AuthenticationType);

For more information about Basic and Digest authentication, see the IIS Help.

Using Impersonation

The authentication and authorization settings in the Web.config file control access to your Web application from the outside world. However, once a user is authenticated, the application runs under the identity of the ASPNET user account by default. The ASPNET account is a limited user account created when you install the Microsoft .NET Framework.

Alternatively, you can set the application to run under the user s account by setting the application s identity element to enable impersonation, as shown here:

<configuration> <system.web> <!-- Impersonate the authenticated user in code --> <identity impersonate="true" /> </system.web> </configuration>

When the user requests a Web form from a folder containing the preceding Web.config settings, the Web form s code executes in the security context of the user s Windows account not the default ASPNET user account. The code inherits the user s permissions (or lack of permissions), and access to resources is granted or denied based on those permissions.

To see the impersonated identity under which code is executing, use the WindowsIdentity class s GetCurrent method, as shown here:

Visual Basic .NET

Response.Write(System.Security.Principal.WindowsIdentity.GetCurrent().Name)

Visual C#

Response.Write(System.Security.Principal.WindowsIdentity.GetCurrent().Name);

The identity element can be used with any type of authentication; however, it is most useful with Windows authentication because Windows authentication users have accounts with specific permissions. Using the preceding Web.config settings with Forms or Passport authentication results in the ASP.NET code impersonating the generic IUSR_machinename account.

You can use the identity element to execute code using a specific Windows account. For example, the following Web.config setting causes code to run under the Administrator account:

<!-- Impersonate the Administrator account --> <identity impersonate="true" username="Administrator" password="O#thip32x" />

You can combine this type of impersonation with folder-level authentication settings to grant authorized users administrative privileges by location. For example, the following Web.config settings allow the user Jane to execute code as the Administrator user in the /Admin folder. All other users are denied access.

<!-- From root-level Web.config file --> <configuration> <system.web> <authentication mode="Windows" /> <authorization> <deny users="?"  /> <!-- Authenticate (but allow) all users. --> </authorization> <!-- Turn off impersonation (default). --> <identity impersonate="false" /> </system.web> </configuration> <!-- From /Admin folder Web.config file --> <configuration> <system.web> <authorization> <allow users="contoso\Jane"  /> <!-- Allow only Jane. --> <deny users="*" /> </authorization> <!-- Impersonate the Administrator account --> <identity impersonate="true" username="Administrator"  password="O#thip32x" /> </system.web> </configuration>

This type of folder-level impersonation can also be used effectively with Forms or Passport authentication, because you are impersonating a specific user account instead of the generic IUSR_machinename account.



MCAD(s)MCSD Self-Paced Training Kit(c) Developing Web Applications With Microsoft Visual Basic. Net and Microsoft V[.  .. ]0-315
MCAD(s)MCSD Self-Paced Training Kit(c) Developing Web Applications With Microsoft Visual Basic. Net and Microsoft V[. .. ]0-315
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 118

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net