ASP.NET Authorization

Discussion in 'ASP.NET 2.0' started by falah gate, Jan 3, 2008.

  1. ASP.NET Authorization




    Authorization determines whether an identity should be granted access to a specific resource. In ASP.NET, there are two ways to authorize access to a given resource:



    • File authorizationFile authorization is performed by the <MSHelp:link tabIndex=0 keywords="T:System.Web.Security.FileAuthorizationModule">FileAuthorizationModule</MSHelp:link>. It checks the access control list (ACL) of the .aspx or .asmx handler file to determine whether a user should have access to the file. ACL permissions are verified for the user's Windows identity (if Windows authentication is enabled) or for the Windows identity of the ASP.NET process. For more information, see ASP.NET Impersonation.



    • URL authorizationURL authorization is performed by the <MSHelp:link tabIndex=0 keywords="T:System.Web.Security.UrlAuthorizationModule">UrlAuthorizationModule</MSHelp:link>, which maps users and roles to URLs in ASP.NET applications. This module can be used to selectively allow or deny access to arbitrary parts of an application (typically directories) for specific users or roles.
    Using URL Authorization



    With URL authorization, you explicitly allow or deny access to a particular directory by user name or role. To do so, you create an authorization section in the configuration file for that directory. To enable URL authorization, you specify a list of users or roles in the <MSHelp:link tabIndex=0 keywords="144E9A7C-D94F-4DD4-BE3A-B47D0E1CED47">allow</MSHelp:link> or <MSHelp:link tabIndex=0 keywords="215C7CF7-129E-43C0-B8DE-8BD70695C992">deny</MSHelp:link> elements of the <MSHelp:link tabIndex=0 keywords="2D3D9BF6-F914-4C30-AD03-32EEA98FA612">authorization</MSHelp:link> section of a configuration file. The permissions established for a directory also apply to its subdirectories, unless configuration files in a subdirectory override them.


    The following shows the syntax for the authorization section:





    [​IMG]</IMG>Copy Code

    <authorization>
    <[allow|deny] users roles verbs />
    </authorization>


    The allow or deny element is required. You must specify either the users or the roles attribute. Both can be included, but both are not required. The verbs attribute is optional.


    The allow and deny elements grant and revoke access, respectively. Each element supports the attributes shown in the following table:





    Attribute
    Description




    users



    Identifies the targeted identities (user accounts) for this element.


    Anonymous users are identified using a question mark (?). You can specify all authenticated users using an asterisk (*).




    roles



    Identifies a role (a <MSHelp:link tabIndex=0 keywords="T:System.Web.Security.RolePrincipal">RolePrincipal</MSHelp:link> object) for the current request that is allowed or denied access to the resource. For more information, see Managing Authorization Using Roles.




    verbs



    Defines the HTTP verbs to which the action applies, such as GET, HEAD, and POST. The default is "*", which specifies all verbs.


    The following example grants access to the
    Code:
    Kim
    identity and members of the
    Code:
    Admins
    role, and denies access to the
    Code:
    John
    identity (unless the
    Code:
    John
    identity is included in the
    Code:
    Admins
    role) and to all anonymous users:





    [​IMG]</IMG>Copy Code

    <authorization>
    <allow users="Kim"/>
    <allow roles="Admins"/>
    <deny users="John"/>
    <deny users="?"/>
    </authorization>


    The following authorization section shows how to allow access to the
    Code:
    John
    identity and deny access to all other users:





    [​IMG]</IMG>Copy Code

    <authorization>
    <allow users="John"/>
    <deny users="*"/>
    </authorization>


    You can specify multiple entities for both the users and roles attributes by using a comma-separated list, as shown in the following example:





    [​IMG]</IMG>Copy Code

    <allow users="John, Kim, contoso\Jane"/>


    Note that if you specify a domain account name, the name must include both the domain and user name (
    Code:
    contoso\Jane
    ).


    The following example allows all users to perform an HTTP GET for a resource, but allows only the
    Code:
    Kim
    identity to perform a POST operation:





    [​IMG]</IMG>Copy Code

    <authorization>
    <allow verbs="GET" users="*"/>
    <allow verbs="POST" users="Kim"/>
    <deny verbs="POST" users="*"/>
    </authorization>


    Rules are applied as follows:



    • Rules contained in application-level configuration files take precedence over inherited rules. The system determines which rule takes precedence by constructing a merged list of all rules for a URL, with the most recent rules (those nearest in the hierarchy) at the head of the list.



    • Given a set of merged rules for an application, ASP.NET starts at the head of the list and checks rules until the first match is found. The default configuration for ASP.NET contains an
      Code:
      <allow users="*">
      element, which authorizes all users. (By default, this rule is applied last.) If no other authorization rules match, the request is allowed. If a match is found and the match is a deny element, the request is returned with the 401 HTTP status code. If an allow element matches, the module allows the request to be processed further.


    In a configuration file, you can also create a <MSHelp:link tabIndex=0 keywords="922ef7d5-da38-4661-b1c6-5b9e5ceda1d5">location</MSHelp:link> element to specify a particular file or directory to which settings in that the location element should apply
     

Share This Page