wcf - 为什么使用基于声明的身份验证需要资源/操作而不是类型/值

Question

我们旧的软件架构使用基于角色的验证。我们现在要使用基于声明的授权。事实上，我认为我们总是使用建模声称的东西，即使我们使用了角色库技术。

最低级别是权限。权限可以是“调用用户服务添加用户”或简称“UserService.Add”。可以将权限分配给组。用户可以是组的成员。最后，通过组成员身份，用户可以拥有一系列权限。

旧系统使用 UserNamePasswordValidator 的组合, IAuthorizationPolicy和 CodeAccessSecurityAttribute要具有写在服务方法上方和调用服务方法时的属性，将检查有效性。如果用户没有所需的权限，访问将被拒绝。工作得很好。

[CompanyRoleRequired(SecurityAction.Demand, Role = "Common.Connect")]
[CompanyRoleRequired(SecurityAction.Demand, Role = "SomeServiceName.Save")]
public void Save(IEnumerable<Data> data)
{
  // code
}

现在我想使用基于声明的授权。保留上面的模型，我将为每个以前的特权创建一个声明，或者为每个具有其操作的有效值的服务创建一个声明。例如，代替“UserService.Add”，我可以添加声明“UserService”，具有前一个特权的人将获得值为“Add”的声明。我想为服务开发人员提供同样方便的访问检查，因此我希望在服务方法上方注释所需的声明。 Microsoft 已经提供了 ClaimsPrincipalPermissionAttribute为了这。

我没有实现 IAuthorizationPolicy，而是实现了 ClaimsAuthorizationManager .

问题一)授权管理器被调用两次。一次使用肥皂网址，一次使用我的属性。我用谷歌搜索了很多，这似乎是设计使然。区分通话并仅检查我的通话没有问题，但也许我什么也没看到。是否有一个选项或一种简单的方法可以不使用 url 调用soap调用并且只调用属性？

问题2)访问检查提供了检查主体是否有 claim 的能力。显然，声明具有类型/名称和值。我本来希望该属性提供这样的接口(interface)。但是，该属性想了解资源和操作。 access check我需要覆盖的功能还需要检查资源和操作。这是为什么？我是否需要将资源/操作映射到我的 AuthorizationManager 中的声明？如果我认为不需要它，是否可以将声明的预期类型和值作为资源和操作放入属性中并将它们 1:1 映射到授权管理器中？或者如果我这样做，我会错过一些重要的安全功能吗？

Answer 1

Q1) 不幸的是这种情况 - 由于“自动”调用和属性/.CheckAccess 都使用相同的声明类型，因此您无法轻松区分两者。我在这里写过:http://leastprivilege.com/2011/04/30/what-i-dont-like-about-wifs-claims-based-authorization/

Q2)你在这里错过了这个概念。这个想法是不检查特定的声明 - 而是用“你在做什么”来注释代码。编写业务代码的人通常不确切知道允许谁调用它(或者确切需要哪些声明)。您只需告诉 authZ 策略您将要添加一个客户(例如)。授权经理的工作是确定委托(delegate)人是否被授权这样做(通过任何方式)。关注点分离。见这里:http://leastprivilege.com/2011/04/30/what-i-like-about-wifs-claims-based-authorization/