Subscribe

RSS Feed (xml)

Using IIS Authentication

To prevent users from accessing certain pages unless they have been authenticated against a Windows user account on the server.

IIS and ASP.NET use a layered security model. When a user requests an ASP.NET Web page over HTTP, the following steps take place:

  1. IIS attempts to authenticate the user. If anonymous access is enabled, IIS automatically logs the user on as the anonymous user (typically the IUSR_[ServerName] account). Otherwise, it requests authentication credentials that it will use to log the user on with another Windows account.

  2. Provided IIS can authenticate the user successfully, it passes the request to ASP.NET with information about the authenticated user. ASP.NET can then use its own security services based on the settings in the Web.config file (for example, denying specific users or groups access to certain pages or directories). In addition, your code can restrict actions programmatically by checking the user information.


  3. If the ASP.NET code accesses any system resources (for example, tries to open a file or connect to a database), the Windows operating system performs its own security checks. Usually, the ASP.NET application code won't actually run under the account of the authenticated user. Thus, these security checks are made against the ASP.NET process account (which is configured using the machine.config file).

The first step to use IIS authentication is to disable anonymous access for the virtual directory. To do so, start IIS Manager (select Settings | Control Panel | Administrative Tools | Internet Information Services from the Start Menu). Then right-click a virtual directory or a subdirectory inside a virtual directory, and choose Properties. Select the Directory Security tab, as shown in below figure.

figure1.JPG

Next, click the Edit button to modify the directory security settings. The window shown below figure will appear. In the bottom half of the window, you can enable one of the Windows authentication methods. However, none of these methods will be used unless you explicitly clear the Anonymous Access check box.

figure2.JPG

You can enable more than one authentication method, in which case the client will use the strongest supported method. If anonymous access is enabled, it's always used. The different authentication methods are described in Table 7. 2.
Table 7.2: Types of Authentication

Mode

Description

Anonymous

The client is not required to submit any information. Users are logged in using the preset anonymous account (typically IUSR_[ServerName]).

Basic

Basic authentication is a part of the HTTP 1.0 standard, and it is supported by almost all browsers and Web servers. When using basic authentication, the browser presents the user with a login box with a user name and password field. This information is then transmitted to IIS, where it is matched with a local Windows user account. Basic authentication should always be combined with SSL because it doesn't encrypt the logon information before transmitting it.

Digest

Digest authentication sends a digest (also known as a cryptographic hash) over the network. Thus, it's much more secure than Basic authentication because intercepted logon information can't be reused. The primary disadvantage is that Digest authentication is supported only by Internet Explorer 5.0 and later versions. Also, your Web server needs to use Active Directory or have access to an Active Directory server.

Integrated

Integrated Windows authentication is the best choice for most intranet scenarios. When using integrated authentication, Internet Explorer sends the logon token for the current user automatically, provided it is on a trusted domain. Integrated authentication is supported only on Internet Explorer 2.0 and later and can't work over proxy servers.

Once you've enabled the appropriate virtual directory security settings, you should make sure that the Web.config file is set to use Windows authentication. In a Visual Studio .NET project, this is the default setting.

<configuration>
<system.web>
<!-- Other settings omitted. -->
<authentication mode="Windows" />
</system.web>
</configuration>

At this point, your virtual directory will require user authentication and your Web application will be able to retrieve the user information. In addition, you can add authorization rules that prevent certain users or groups from accessing Web pages or subdirectories. You do this by adding <allow> and <deny> tags to the <authorization> section of the Web.config file. For example, you can create a subdirectory with the following Web.config file contents:

<configuration>
<system.web>

<authorization>
<deny roles="Guest,Associate" />
<allow users="matthew" />
<deny users="*" />
</authorization>

</system.web>
</configuration>

ASP.NET examines rules in the order they appear and stops when it finds a match. In this example, users in the Guest or Associate groups will automatically be denied. The user matthew will be permitted (unless he's a member of one of the previously forbidden groups). All other users will be denied. In this case, these are local groups and user accounts. If you want to refer to a domain account, use the pathlike syntax [DomainName]\[UserName] instead.

Notice that in this example, the Web.config file doesn't contain an <authentication> section. This omission is because the authentication is configured in the Web.config file in the Web application directory. Subdirectories can set their own authorization rules, but they can't change the mode of authentication.

Another option is to deny access to specific pages using the <location> attribute:

<configuration>  
<system.web>
<!-- Other settings omitted. -->
</system.web>

<location path="SecurePage.aspx">
<system.web>
<authorization>
<deny roles="Guest" />
</authorization>
</system.web>
</location>

</configuration>

Finally, you can write your own authorization logic by examining the user identity in your Web page code using the Page.User property, which provides a WindowsPrincipal object. You can retrieve the user name from the WindowsPrincipal.Identity.Name property, and you can test group membership using the WindowsPrincipal.IsInRole method. The following Web page code demonstrates these techniques:


using System;
using System.Web;
using System.Web.UI.WebControls;
using System.Web.Security.Principal;

public class WindowsSecurityTest : System.Web.UI.Page {

protected System.Web.UI.WebControls.Label lblMessage;

// (Designer code omitted.)

private void Page_Load(object sender, System.EventArgs e) {

// Get the IIS-authenticated identity.
WindowsIdentity identity = (WindowsIdentity)User.Identity;

// Test if it is an Administrator.
bool isAdmin = User.IsInRole(@"BUILTIN\Administrators");

// Display some information about the identity.
lblMessage.Text = "You have reached the secured page, " +
User.Identity.Name + "." +
"<br><br>Authentication Type: " +
identity.AuthenticationType.ToString() +
"<br>Anonymous: " + identity.IsAnonymous.ToString() +
"<br>Authenticated: " + identity.IsAuthenticated.ToString() +
"<br>Guest: " + identity.IsGuest.ToString() +
"<br>System: " + identity.IsSystem.ToString() +
"<br>Administrator: " + isAdmin.ToString();
}
}

Technorati :

No comments:

Variety in the Web World