使用 ThinkTecture ClaimsAuthorizeAttribute 对基于声明的授权进行单元测试答案

【问题标题】：Unit testing claims based authorization with ThinkTecture ClaimsAuthorizeAttribute使用 ThinkTecture ClaimsAuthorizeAttribute 对基于声明的授权进行单元测试
【发布时间】：2014-01-09 13:35:16
【问题描述】：

我们正在使用 ThinkTecture 的 MVC ClaimsAuthorizeAttribute 控制对应用程序资源和操作的访问，并希望能够使用 Moq 包含一些单元测试覆盖率。

理想情况下，我想编写一个测试，请求一个控制器操作，并用以下内容装饰：

[ClaimsAuthorize("operation_x", "resource_1")]

...以便在执行测试时进入我们AuthorizationManager的CheckAccess覆盖方法。

我们的 CheckAccess 覆盖只是从传入的 AuthorizationContext（“operation_x”和“resource_1”）获取操作和资源，并确定 Principal 是否将资源/操作组合作为声明，如果找到匹配项则返回 true。

测试将根据我们的 CheckAccess 覆盖的结果通过或失败。

我在网上找到的大多数示例都是关于单元测试自定义 Authorize 属性或测试控制器操作是否已被 AuthzAttribute 修饰。测试 ThinkTecture 的 ClaimsAuthorize 属性的示例似乎并不多。

是否有可能实现我所描述的？如果有，请指教！

谢谢

【问题讨论】：

标签： security authorization claims thinktecture-ident-model

【解决方案1】：

您可能希望做更多的工作 - 您不需要测试 ThinkTecture 的 ClaimsAuthorizeAttribute，因为 ThinkTecture 已经这样做了。您应该编写测试来测试您自己的代码 - 即在您的 CheckAccess 覆盖范围内执行的操作的结果。

如果您想检查 ThinkTecture 属性是否正常工作，您应该考虑设置一个 integration 测试，该测试会导致相关控制器操作被调用。

【讨论】：

感谢史蒂夫的回复。确实——我们调用我的 CheckAccess 覆盖的结果应该是这里的主要关注点。我认为您的意思是，通过请求控制器操作（并执行 authz 管道）的测试代理调用 CheckAccess 并没有比直接在测试方法中调用 CheckAccess 带来额外的好处？
所以在最新版本中 ClaimsAuthorizeAttribute 似乎已重命名为 ResourceActionAuthorizeAttribute，但我还没有找到如何使用它的好例子。项目中的示例代码不再构建，因为它尚未从 ClaimsAuthorizeAttribute 重命名。任何有关文档和示例的建议都将受到欢迎。谢谢。