授权的目的是确定是否应该授予某个标识对给定资源请求的访问权限类型。有两种基本方式来授予对给定资源的访问权限：
- 文件授权
文件授权由 FileAuthorizationModule 执行，它在使用 Windows 身份验证时处于活动状态。它执行 .aspx 或 .asmx 处 理程序文件的访问控制列表 (ACL) 检查以确定用户是否应该具有访问权限。应用程序可以进一步使用模拟在正在访问的资源上 进行资源检查。
- URL 授权
URL 授权由 URLAuthorizationModule 执 行，它将用户和角色映射到 URL 命名空间的块上。此模块实现正和负两种授权断言。也就是说，对于某些集、用户或角色，该模 块可用于有选择地允许或拒绝对 URL 命名空间的任意部分的访问。
URLAuthorizationModule 在任何 时候都是可用的。只需在配置文件的 <authorization> 部分的 <allow> 或 <deny> 元素中放置用户和/或 角色的列表即可。
若要建立访问特定目录的条件，则必须将一个包含 <authorization> 部分的配置文件放置在该目录中。为该目录设置的条件也会应用到其子目录，除非子目录中的配置文件重写这些条件。此部分的常规语法如下所 示。
<[element] [users] [roles] [verbs]/>
元素是必需的。必须包含 users 或 roles 属性。可以同时包含二者，但这不是必需的。verbs 属性是可选的。
允许的元素有 <allow> 和 <deny>，它们分别授予和撤消访问权限。每个元素支 持三个属性，这些属性在下面的表中定义。
属性
说明
roles
标识此元素的目标角色。请求所关联的 IPrincipal 对象 确定角色成员。可以将任意 IPrincipal 对象附加到 给定请求的上下文中，这些对象可通过您喜欢的任何方式来确定角色成员。例如，默认的 WindowsPrincipal 类使用 Microsoft Windows NT 组来确定角色成员。
users
标识此元素的目标身份。
verbs
定义操作所要应用到的 HTTP 谓词，如 GET、HEAD 和 POST。
还会拒绝匿名用户。
以下示例向 Kim 和管理角色的成员授予权限，而拒绝 John 和 所有匿名用户：
<authorization>
<allow users="Kim"/>
<allow roles="Admins"/>
<deny users="John"/>
<deny users="?"/>
</authorization>
用户和角色都可以通过使用逗号分隔的列表来引用多个实体，如下面的示例所示。
<allow users="John, Kim, contoso\Jane"/>
注意，域帐户 (contoso\Jane) 必须同时包括域和用户名的组合。
除身份名称外，还有两种特殊身份，如下表所示。
标识
说明
*
指所有身份
?
指匿名身份
若要允许 John 并拒绝其他任何人，可以构造下面的配置部分。
<authorization>
<allow users="John"/>
<deny users="*"/>
</authorization>
下面的示例允许每个人使用 GET，但只有 Kim 可以使用 POST。
<authorization>
<allow verb="GET" users="*"/>
<allow verb="POST" users="Kim"/>
<deny verb="POST" users="*"/>
</authorization>
使用下面的试探法应用规则：
- 位于较低目录级别的配置文件中包含的规则优先于位于较高目录级别的规则。系统通过构造一个 URL 的所有规 则的合并列表，其中最近（层次结构中距离最近）的规则位于列表头，来确定哪条规则优先。
- 给定 URL 的一组合并的规则，系统从列表头开始，检查规则直到找到第一个匹配项为止。注意，ASP.NET 的默认配置包含向所有用户授权的 <allow users="*"> 元素。如果没有匹配的规则，则将允许请求，除非另外拒绝。如果找到匹配项并且匹配项是 <deny> 元素，则它将返回 401 状态代码。应用程序或站点可以方便地配置位于其站点或应用程序顶层的 <deny users="*"> 元素以防止此行为。
如果是 <allow> 匹 配，则模块不执行任何操作，允许进一步处理请求。
还有 <location> 标 记，您可以使用该标记来指定特定的文件或目录，由该标记环绕（即在 <location> 和 </location> 标 记之间）的那些设置将应用到该文件或目录。
 By ACReaper)
