声明感知 Web 应用程序和服务中的授权
更新时间：2015 年 6 月 19 日
适用于：Azure
应用于
Microsoft Azure Active Directory 访问控制（也称为访问控制服务或 ACS）
Windows® Identity Foundation (WIF)
ASP.NET
Windows Communication Foundation (WCF)
总结
在依赖方应用程序中，授权可确定允许已经过身份验证的标识访问的资源以及允许该标识对这些资源执行的操作。 授权不当会导致信息泄露和数据篡改。 本主题概述了使用 ACS 和 WIF 实现声明感知 ASP.NET Web 应用程序和服务的授权的可用方法。
目标
列出使用声明的授权方式。
概述每种方式的高级设计。
阐明每种方式的优点和缺点。
概述
.NET Framework 自其第一个版本开始便已提供用于实现授权的灵活机制。 此机制基于两个简单接口 — IPrincipal 和 IIentity。 IIentity 的具体实现表示一个经过身份验证的用户。 例如， WindowsIdentity 实现表示由 Active Directory 进行身份验证的用户， GenericIdentity 表示通过自定义身份验证进行身份验证的用户。 有了 IPrincipal 的具体实现，就可以使用角色根据角色存储检查权限。 例如，WindowsPrincipal 检查 Active Directory 组中 WindowsIdentity 的成员资格。 此检查通过调用 IPrincipal 接口上的 IsInRole 方法执行。 基于角色检查访问权称作基于角色的访问控制 (RBAC)。 本主题的“基于角色的访问控制”部分对 RBAC 做了介绍。 声明可用于携带有关角色的信息以支持熟悉的、基于角色的授权机制。
声明还可用于达成更丰富的、超出角色范围之外的授权决策。 声明可基于几乎任何内容 — 年龄、邮编、鞋码，等等。 基于任意声明的检查访问称为基于声明的访问控制 (CBAC) 或基于声明的授权。 本主题的“基于声明的访问控制”部分介绍了基于声明的授权。
授权检查在应用程序端执行，而不是在 ACS 端执行。 ACS 充当安全令牌服务， (STS) 颁发将声明传送到应用程序的令牌。 令牌使用标识提供者的声明和 ACS 本身（可选）使用规则引擎来扩充令牌。 当应用程序收到带有声明的令牌时，它可以分析该令牌、提取相关声明并使用 RBAC 或基于声明的方法来做出授权决策。 系统使用 WIF 来分析令牌，以便使用令牌通过易用的应用程序编程接口 (API) 来做出授权决策。 有关 WIF 的详细信息，请参阅 WIF SDK (https://go.microsoft.com/fwlink/?LinkID=187481) 。 考虑如何在声明感知应用程序和服务中授权时，请参考下图。 请注意，在身份验证成功之后，标识提供程序会生成一个令牌（图中的 IdP 令牌）。 IDP 令牌可由 ACS 规则引擎转换。 ACS 可以添加、删除或更改标识提供者颁发令牌中的声明。 最后，ACS 颁发的令牌将发送到应用程序，并由 WIF 处理。 使用 RBAC 或 CBAC 方法可在 WIF 中完成访问检查。
.gif "ACS v2 WIF Authorization")
基于角色的访问控制
RBAC 是一种授权方法，其中的用户权限由基于用户角色的应用程序管理和强制实施。 如果用户具有执行操作所需的角色，则将授予访问权；否则，访问将被拒绝。
IPrincipal.IsInRole 方法
若要在声明感知应用程序中实现 RBAC 方法，请使用 IPrinicpal 接口 IsInRole() 方法，就像你在非声明感知应用程序中一样操作。 可通过多种方式使用 IsInRole() 方法：
显式调用 IPrincipal.IsInRole("Administrator")。 在此方法中，结果为布尔值。 在条件语句中使用它。 可在代码中的任意位置使用它。
使用安全请求 PrincipalPermission.Demand()。 在此方法中，如果未满足要求，则结果为异常。 这应适合您的异常处理策略。 从性能角度看，引发异常比返回布尔值需要消耗更多的资源。 可在代码中的任何位置进行使用。
使用声明性属性 [PrincipalPermission(SecurityAction.Demand, Role = "Administrator")]。 此方法称为声明性方法，因为它用于修饰方法。 它不能在方法实现中的代码块内使用。 如果未满足要求，则结果为异常。 您应确保它适合您的异常处理策略。
使用 URL 授权，使用 <web.config中的授权>部分。在 URL 级别管理授权时，此方法适用。 这是前面提到的方法中最粗糙的方法。 此方法的优点在于，更改是在配置文件中做出的，这意味着无需编译代码即可利用此更改。
将角色表示为声明
调用 IsInRole() 方法时，将会检查当前用户是否具有该角色。 在声明感知应用程序中，该角色由应在令牌中可用的角色声明类型表示。 使用以下 URI 表示此角色声明类型：
https://schemas.microsoft.com/ws/2008/06/identity/claims/role
可通过几种方法增强带角色声明类型的令牌：
使用 ACS 规则引擎 — 在本例中，使用 ACS 管理门户或 ACS 管理服务创建生成特定角色类型的声明的声明转换规则。 有关规则和令牌转换的详细信息，请参阅 规则组和规则 以及如何 ：使用规则实现令牌转换逻辑。
使用 ClaimsAuthenticationManager 将任意声明转换为声明角色类型 — ClaimsAuthenticationManager 是 WIF 随附的一个组件。 它允许在请求启动应用程序时拦截请求，并通过添加、更改或删除声明来检查并转换令牌。 有关如何使用 ClaimsAuthenticationManager 转换声明的详细信息，请参阅如何：在声明感知 ASP.NET 应用程序中使用 WIF 和 ACS 实现基于角色的 访问控制 (RBAC)
使用 samlSecurityTokenRequirement 配置节将任意声明映射到角色类型 — 这是一种声明性方式，它只使用配置来完成声明转换，而无需用户编写代码。
基于声明的访问控制
CBAC 是一种授权方式，其中，允许还是拒绝访问的授权决策取决于使用声明中的可用数据做出决策的任意逻辑。 请记住，对于 RBAC，仅使用角色类型声明。 角色类型声明用于检查用户是否属于特定角色。 若要阐释使用基于声明的授权方法做出授权决策的过程，请考虑以下步骤：
应用程序收到一个请求。
应用程序提取传入声明。
应用程序将声明传递给决策逻辑机制。 该机制可以是内存中的代码或者对 Web 服务的调用、对数据库的查询，它还可以调用复杂的规则引擎。
决策机制根据声明计算结果。
如果结果为 true，则授予访问权；如果结果为 false，则拒绝访问。 例如，该规则可能是用户年龄在 21 岁或更高，位于华盛顿州，并且通过 Windows Live ID (Microsoft 帐户) 进行身份验证。
ACS 充当颁发携带声明的令牌的 STS。 可以使用 ACS 规则引擎控制发出哪些声明（声明类型和值）。 若要详细了解 ACS 规则引擎，请参阅 规则组和规则 以及如何 ：使用规则实现令牌转换逻辑。 ClaimsAuthorizationManager 是在声明感知应用程序中实现 CBAC 的关键。 ClaimsAuthorizationManager 是 WIF 随附的一个组件。 ClaimsAuthorizationManager 允许您拦截传入请求，并实现选定的任何逻辑以根据传入声明做出授权决策。 它也是一个扩展点，授权决策可以在其中外部化并与应用程序代码分离。 在需要更改授权逻辑时，这变得非常重要。 在这种情况下，使用 ClaimsAuthorizationManager 将不会影响应用程序的完整性，从而降低了更改导致应用程序错误的可能性。 若要详细了解如何使用 ClaimsAuthorizationManager 实现基于声明的访问控制，请参阅如何：使用 WIF 和 ACS 在声明感知 ASP.NET 应用程序中实现声明授权。