Authentication and Authorization for ASP.Net Application

Authentication and Authorization for ASP.Net Application

 

 

介绍如何使用ASP.Net内置的安全特性，通过定制web.config配置文件中的Authentication, Authorization, and Impersonation等等元素来控制或设定web application的认证和授权访问。虽然，开发人员完全可以通过自己编写代码来达到相同的目的，但是善用.Net framework提供的一些现有特性，然后在此基础上开发，应该会更好。

 

Introduction

An easy way to organize your protected resources within your Web site is to place them in their own subdirectory beneath the application root. The process of customizing configuration for a subdirectory is simple enough, however a few common misunderstandings are encountered along the way, which can lead developers to take the wrong path. This article explains how to set up your directory structure, where to place your files, and how you can define your configuration settings.

 

I know that you can develop full functions to control authentication and authorization instead of using any built-in features of .Net framework, but it’s very convenient and helpful to design authentication and authorization functionalities based on these existing features provided by .Net framework.

 

Configuration Inheritance

At runtime when an ASP.NET application resource is requested, its virtual directory path (through IIS) is used to gather a hierarchical collection of configuration files. This starts with machine.config, which configures your entire Web server (actually, the entire .NET Framework runtime environment), then looks into the root of the Web application and its subdirectories for web.config files that may contain modifications to this default configuration.

 

There are no security settings within the machine.config file (by default) so to secure any resources, so you typically take care of this within the web.config for the Web application, and possibly within a web.config placed in a protected subdirectory of the same application. First you have to have forms authentication enabled for the application which is handled in the application root's web.config. Then, to protect resources in subdirectories you can either place a web.config file in a protected subdirectory to reject anonymous users for all resources in that subdirectory, or use the <location> tag in the application's web.config to do achieve the same result.

 

Authentication, Authorization, and Impersonation

These three terms are used thoroughly when discuss security in general. For clarification purposes to those unfamiliar with the differences between the terms, we include definitions here.

1, Authentication

The process of verifying that the user is who they claim to be, usually through some username/password verification scheme

2, Authorization

The process of verifying what resources an authenticated user has access to

3, Impersonation

The process of having the ASP.NET worker process runs as an authenticated or anonymous user so that authorization checks can be performed

 

Configuring Authentication

Authentication refers to how a user's identify is verified. There are 4 different authentication options:

Windows: 将 Windows 验证指定为默认的身份验证模式。当使用以下任意形式的 Microsoft Internet 信息服务 (IIS) 身份验证时使用该模式：基本、简要、集成的 Windows 验证 (NTLM/Kerberos) 或证书。

Forms: 将 ASP.NET 基于窗体的身份验证指定为默认的身份验证模式。

Passport: 将 Microsoft Passport 身份验证指定为默认的身份验证模式。

None: 不指定任何身份验证。只有匿名用户是预期的或者应用程序可以处理事件以提供其自身的身份验证。

Authentication is configured in the web.config file for the application. The <authentication> section of the web.config file looks like this:

<authentication mode="[Windows|Forms|Passport|None]">

     <forms name="[name]" loginUrl="[url]" >

            <credentials passwordFormat="[Clear, SHA1, MD5]">

                 <user name="[UserName]" password="[password]"/>

            </credentials>

        </forms>

        <passport redirectUrl="internal" />

</authentication>

For forms authentication, the <forms> tag provides settings for the name of the cookie given to the user (.ASPAUTHX is the default), and the path to the login form for non-authenticated users. For passport authentication, the <passport> tag allows you to indicate a redirect page after the user is authenticated. Otherwise, the passport service redirects a user to the page he/she originally requested.

 

Please keep in mind the following limitations in .Net framework 1.1:

1. The <authentication> section is only supported in IIS application directories, which doesn't include subdirectories of an IIS application.

2. In protected subdirectories, place a web.config with the <authorization> section required to prevent access.

 

Web.config Examples – authentication元素使用示例：

1, Windows Authentication

<authentication mode="Windows">

</authentication>

 

2, Forms Authentication

<authentication mode="forms">

     <forms forms="MyApp" loginurl="/login.aspx" decryptionkey="1!#$$*13^">

         <credentials passwordFormat=SHA1>

             <user name="Bill" password="9611E4F94EC4972D5A537EA28C69F89AD28E5B36"/>

             <user name="Steve" password="BA7157A99DFE9DD70A94D89844A4B4993B10168F"/>

         </credentials>

     </forms>

</authentication>

 

3, Passport Authentication

<authentication mode= "Passport">

</authentication>

 

Configuring Authorization

Authorization is the next stage after Authentication. Once you have confirmed the identity of the user, you need to find out what they are permitted to see. Like authentication, there are web.config sections dealing with authorization, or you could use custom code to authorize users.

Authorization in Web.Config 示例：

 

Authorization is controlled in an <%authorization%> tag, via <allow> and <deny> elements. For example, the following authorization configuration allows Steve and Administrators to access the web application, but denies everyone else.

 

<authorization>

  <allow users="Steve" />

  <allow roles="Administrators" />

  <deny users="*" />

</authorization>

The asterisk (*) wildcard is used to denote all users. The question mark (?) is used to denote all non-authenticated users. The users attribute allows you to list users who should be allowed or denied access. Likewise, the roles attribute is used for role-based authorization and can be used to allow or deny users in those roles.

 

Placing web.config files beneath subdirectories that require custom configuration apart from the base application configuration, makes it possible to clearly distinguish configuration settings for different directories. The drawback of this is in configuration parsing, since now the runtime must retrieve the maching.config, the application web.config and the hierarchy of subdirectory web.config files when resources are requested. There is an alternative removing some of this overhead named location element.

 

Location tag

 

Using a <location> tag, you can specify authorization settings for subdirectories in your web application. For example, your site may be public, but you use forms authentication to authenticate members and allow them access to a MembersOnly directory. The following web.config file (note that location is not inside the system.web tag) shows how to specify authentication settings for the MembersOnly directory.

 

Location tag是一个值得推荐的替代方案，可以代替子目录的web.config配置文件。这样，只需要在web application的根目录存放一个web.config配置文件，来控制其他子目录的认证/授权设置。如下是一个简单的示例：（注：如果在该子目录，如MembersOnly，也有一个web.config配置文件，则该子目录的web.config配置文件可以覆盖根目录下location元素的设置）

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<system.web>

    <authentication mode="Forms">

        <forms loginUrl="Registration/login.aspx" name="OurInternetApp" timeout="30" path="/"></forms>

    </authentication>

    <authorization>

        <allow users="?" />

    </authorization>

</system.web>

<location path="MembersOnly">

    <system.web>

        <authorization>

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

        </authorization>

    </system.web>

</location>

</configuration>

 

Comments on the <location> approach:

• Can control configuration from a single web.config for the whole web application
• Means that fewer hierarchical configuration files to collect to access a resource, thus less overhead requesting the resource (the first time, since it is cached after that)
• Can deny subdirectory web.config overrides using allowOverride attribute

 

Comments on subdirectory web.config settings:

• Can allow divided development efforts to control their own configuration requirements

·         Application will fail if overrides are rejected by <location> settings with the following: <location path="articles" allowOverride="false">

 

Impersonation

 

Impersonation allows you to run an ASP.NET application as a specified user. Normally, the ASP.NET worker process runs as IUSR_[MACHINENAME]. Using an <impersonate> tag in the web.config file, you can configure impersonation as follows:

 

<identity impersonate="true" userName="CompanyDomain\Steve" password="password" />

 

 

Appendix about the article

I notice that it’s a good feature of ASP.Net when I’m analyzing the enterprise sample named Duwamish 7.0. So I decide to have a good command of it in future web application projects based on .Net framework.

 

The most content of the article comes from the following references. Pasting here is only for learning purpose.

 

Any questions or opinions, please make comments below. Thanks.

 

 

References:

1, Michele Leroux Bustamante, Forms Authorization for ASP.Net Application Subdirectories, http://www.theserverside.net/articles/article.tss?l=FormAuthentication

2, Implementing and Configuring Security, http://www.dotnetcoders.com/web/learning/cert/exams/services/security.aspx

3, MSDN, Authentication, Authorization, Impersonation