Understanding access rules
The primary purpose of establishing roles is to provide you with an easy way to manage access rules for groups of users. You create users and then assign the users to roles (in Windows, to groups). A typical use is to then create a set of pages that you want to restrict to certain users. Often you isolate these restricted pages in a folder by themselves. Then you can use the Web Site Administration Tool to define rules that grant and deny access to restricted folders. For example, you can configure the site so that members or managers have access to the pages in the restricted folder and all other users are denied access. If an unauthorized user tries to view a restricted page, the user either sees an error or is redirected to a page that you specify.
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 allow or deny elements of the authorization 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:
<[allow|deny] users roles verbs />
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:
|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 RolePrincipal object) for the current request that is allowed or denied access to the resource.|
|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 Kim identity and members of the Admins role, and denies access to the John identity (unless the John identity is included in the Admins role) and to all anonymous users:
<authorization> <allow users="Kim"/> <allow roles="Admins"/> <deny users="John"/> <deny users="?"/> </authorization>
The following authorization section shows how to allow access to the John identity and deny access to all other users:
<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:
<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 (contoso\Jane).
The following example allows all users to perform an HTTP GET for a resource, but allows only the Kim identity to perform a POST operation:
<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 <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.
To modify access rules
- In the Website menu, click ASP.NET Configuration.
- Click the Security tab.
- Under Access Rules, click Manage access rules.
- Click the Add new access rule link.
- Under Select a directory for this rule, select the MembersPages folder.
- Under Rule applies to, select All users.
- Under Permission, select Deny and then click OK.This rule ensures that everyone is denied access to the MembersPages folder.
- Click the Add new access rule link.
- Select the MembersPages folder again.
- Under Rule applies to, select Role and select Member from the drop-down list.
- Under Permission, select Allow, click OK, and then click Done.The rule you just created allows only users who are in the Member role to access the MembersPages folder. The member1 user is denied access to the MembersPages folder although member1 is assigned to Members role. This is because the rule that allows access to the Members role is lower in the list than the rule that denies all users access. To make sure that the member1 user can access the folder, you must move the rule that allows users who are assigned to Members role above the one that denies access to all users.
- Return to the Security tab and click Manage access rules.
- If the MembersPages folder is not selected, select it.
- Under Users and Roles, click Member and click Move Up to move Member to the top of the list.
- Click Done to return to the Security tab.