本文档已存档,并且将不进行维护。

声明感知 Web 应用程序和服务中的授权

发布时间: 2011年4月

更新时间: 2015年6月

应用到: Azure

  • Microsoft Azure Active Directory 访问控制(也称为访问控制服务或 ACS)

  • Windows® Identity Foundation (WIF)

  • ASP.NET

  • Windows Communication Foundation (WCF)

在信赖方应用程序中,授权决定了身份验证标识可访问的资源以及可对这些资源执行的操作。授权不当或较弱会导致信息泄露和数据篡改。本主题概述了使用 ACS 和 WIF 对声明感知 ASP.NET Web 应用程序和服务实施授权的可用方式。

  • 列出使用声明的授权方式。

  • 概述每种方式的高级设计。

  • 阐明每种方式的优点和缺点。

.NET Framework 从第一版开始就提供了用于实现授权的灵活机制。此机制基于两个简单接口 — IPrincipalIIentityIIentity 的具体实现表示一个经过身份验证的用户。例如,WindowsIdentity 实现表示由 Active Directory 进行身份验证的用户,GenericIdentity 表示由自定义身份验证进行验证的用户。有了 IPrincipal 的具体实现,就可以使用角色根据角色存储检查权限。例如,WindowsPrincipal 检查 WindowsIdentity 在 Active Directory 组中的成员身份。此检查通过调用 IPrincipal 接口上的 IsInRole 方法执行。基于角色的检查访问称为基于角色的访问控制 (RBAC)。本主题的“基于角色的访问控制”部分对 RBAC 做了介绍。声明可用于携带有关角色的信息,以支持熟悉的、基于角色的授权机制。

声明还可用于达成更丰富的、超出角色范围之外的授权决策。声明可基于几乎任何内容 — 年龄、邮编、鞋码,等等。基于任意声明的检查访问称为基于声明的访问控制 (CBAC) 或基于声明的授权。本主题的“基于声明的访问控制”部分介绍了基于声明的授权。

授权检查在应用程序端而不在 ACS 端执行。ACS 作为一种安全令牌服务 (STS),可以给应用程序颁发携带声明的令牌。令牌可通过标识提供程序提供的声明或 ACS 本身使用其规则引擎来加以丰富。当应用程序收到带有声明的令牌时,它可以分析该令牌、提取相关声明并使用 RBAC 或基于声明的方法来做出授权决策。系统使用 WIF 来分析令牌,以便使用令牌通过易用的应用程序编程接口 (API) 来做出授权决策。有关 WIF 的详细信息,请参阅 WIF SDK (http://go.microsoft.com/fwlink/?LinkID=187481)。考虑如何在声明感知应用程序和服务中授权时,请参考下图。请注意,在身份验证成功之后,标识提供程序会生成一个令牌(图中的 IdP 令牌)。IdP 令牌可以由 ACS 规则引擎转换。ACS 可以添加、删除或更改标识提供程序所颁发令牌中携带的声明。最终,由 ACS 颁发的令牌将发送到应用程序并由 WIF 进行处理。使用 RBAC 或 CBAC 方法可在 WIF 中完成访问检查。

ACS v2 WIF 授权

RBAC 是一种可通过应用程序基于用户角色管理用户权限并强制实施的授权方法。如果用户具有执行操作所需的角色,则向其授予访问权限;否则,将拒绝其访问。

若要在声明感知应用程序中实现 RBAC 方法,请使用 IPrinicpal 接口 IsInRole() 方法,就像你在非声明感知应用程序中一样操作。可通过多种方式使用 IsInRole() 方法:

  • 显式调用 IPrincipal.IsInRole("Administrator")。使用这种方式时,结果为布尔值。你可以在条件语句中使用该调用,还可以在代码中的任意位置使用该调用。

  • 使用安全请求 PrincipalPermission.Demand()。使用这种方式时,如果请求没有得到满足,则结果为异常。这应符合你的异常处理策略。从性能角度看,引发异常比返回布尔值需要消耗更多的资源。你可以在代码中的任意位置使用该安全请求。

  • 使用声明性属性 [PrincipalPermission(SecurityAction.Demand, Role = "Administrator")]。这种方式之所以称为声明性方式,是因为它可用于修饰方法,而不能在方法实现内的代码块中使用。如果请求没有得到满足,则结果为异常。你应该确保它符合你的异常处理策略。

  • 使用 URL 授权,即使用 web.config 中的 <authorization> 节。这种方式在管理 URL 级别的授权时非常适用。在上面提到的所有方式中,这是粒度级最低的方式。这种方式的优点在于,更改都是在配置文件中进行的,意味着无需编译代码即可利用更改。

调用 IsInRole() 方法时,将会检查当前用户是否具有该角色。在声明感知应用程序中,角色通过令牌中提供的角色声明类型来表示。角色声明类型使用以下 URI 来表示:

http://schemas.microsoft.com/ws/2008/06/identity/claims/role

可使用多种方式来通过角色声明类型丰富令牌:

  • 使用 ACS 规则引擎 — 在此情况下,你可以使用 ACS 管理门户或 ACS 管理服务创建一个规则,以创建生成特定角色类型的声明的声明转换规则。有关规则和令牌转换的详细信息,请参阅规则组和规则操作方法:使用规则实现令牌转换逻辑

  • 使用 ClaimsAuthenticationManager 将任意声明转换为声明角色类型 — ClaimsAuthenticationManager 是 WIF 随附的一个组件。通过该组件,可以在启动应用程序时截获请求,并通过添加、更改或删除声明的方式检查并转换令牌。有关如何使用 ClaimsAuthenticationManager 转换声明的详细信息,请参阅操作方法:在声明感知 ASP.NET 应用程序中使用 WIF 和 ACS 实施基于角色的访问控制 (RBAC)

  • 使用 samlSecurityTokenRequirement 配置节将任意声明映射到角色类型 — 这是一种声明性方式,它只使用配置来完成声明转换,而无需用户编写代码。

CBAC 是一种授权方式,其中,允许还是拒绝访问的授权决策取决于使用声明中的可用数据做出决策的任意逻辑。前面提到过,在 RBAC 中,唯一使用的声明是角色类型声明。角色类型声明用于检查用户是否属于特定角色。为了演示使用基于声明的授权方法做出授权决策这一过程,我们编写了以下步骤供你参考:

  1. 应用程序收到一个请求。

  2. 应用程序提取传入声明。

  3. 应用程序将声明传递到决策逻辑机制。该机制可以是内存中的代码或者对 Web 服务的调用、对数据库的查询,它还可以调用复杂的规则引擎。

  4. 决策机制基于声明来计算结果。

  5. 如果结果为 true,则授予访问权限;如果为 false,则拒绝访问。例如,规则可能是:用户年龄在 21 岁或以上,居住在华盛顿州,并已通过 Windows Live ID(Microsoft 帐户) 的身份验证。

ACS 充当颁发令牌的 STS,令牌中携带了声明。你可以使用 ACS 规则引擎控制要颁发哪些声明 — 包括声明的类型和值。若要了解有关 ACS 规则引擎的详细信息,请参阅规则组和规则操作方法:使用规则实现令牌转换逻辑。ClaimsAuthorizationManager 是在声明感知应用程序中实现 CBAC 的关键。ClaimsAuthorizationManager 是 WIF 随附的一个组件。通过 ClaimsAuthorizationManager,你可以截获传入请求并实施所选的任何逻辑,从而基于传入声明做出授权决策。它也是一个扩展点,授权决策可以在其中外部化并与应用程序代码分离。需要更改授权逻辑时,这项功能就变得非常重要。在这种情况下,使用 ClaimsAuthorizationManager 不会影响应用程序的完整性,从而降低了应用程序由于更改而出错的可能性。若要了解有关如何使用 ClaimsAuthorizationManager 实现基于声明的访问控制的详细信息,请参阅操作方法:使用 WIF 和 ACS 在声明感知 ASP.NET 应用程序中实现声明授权

另请参阅

显示: