为什么需要资源/操作而不是使用基于声明的auth的类型/值

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"而不是"UserService.Add",而具有前一个特权的人将获得值为"Add"的声明.我想为服务开发人员提供相同的访问检查,因此我希望在服务方法之上注释所需的声明.Microsoft已为此提供了ClaimsPrincipalPermissionAttribute.

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

问题1)授权管理器被调用两次.一次使用肥皂网址,一次使用我的属性.我google了很多,似乎是设计的.我没有区分电话和只检查我的电话的问题,但也许我没有看到什么.是否有一个选项或一种简单的方法可以不使用URL调用soap调用,只调用属性？

问题2)访问检查提供了检查市政是否有索赔的能力.显然,索赔具有类型/名称和值.我本来希望该属性提供这样的接口.但是,该属性想要了解资源和操作.我需要覆盖的访问检查功能还需要检查资源和操作.这是为什么？我是否需要将资源/操作映射到AuthorizationManager中的声明？如果我没有看到任何需要,是否可以将索引的预期类型和值作为资源和操作放在属性中并在授权管理器中以1:1映射它们？或者如果我这样做,我会错过一些重要的安全功能吗？

Answer 1

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

Q2)你在这里错过了这个概念.我们的想法是不检查具体的声明 - 而是用"你在做什么"来注释代码.编写业务代码的人通常不知道究竟允许谁调用它(或者确切需要哪些声明).您只告诉authZ poliy您即将添加客户(作为示例).授权经理的工作是弄清楚委托人是否有权这样做(无论如何).关注点分离.见这里:http://leastprivilege.com/2011/04/30/what-i-like-about-wifs-claims-based-authorization/