OData WebAPI 2复杂授权

Question

我们有一个Web Api 2 OData v3服务,我们需要实现相当复杂的授权.我们在客户端代码中使用Breeze,当Breeze的OData v4版本发布时,我们将API升级到OData v4,因此解决方案需要能够在两个OData版本上运行.

此图给出了我们正在使用的实体模型的基本视图(抱歉,图像的信誉点不够):

 ServiceCompany
     |   
     |  
    /|\  
Manufacturer
     |   
     |  
    /|\    
    Site
     |   
     |  
    /|\  
  SiteArea  -------
     |            |
     |            |            
    /|\          /|\ 
 Equipment     Instrument
                  |
                  |
                 /|\
               Channel

SiteArea具有"OperatingFunction"属性 - 这表示在此站点区域位置发生制造过程的哪个阶段.

用户可能是

• 一个人坐在制造商级别并且可以访问他们的所有站点数据
• 一个人坐在制造商级别并且可以访问他们的SiteAreas的一些但不是全部,因此只能访问他们的SiteArea数据的子部分
• 坐在ServiceCompany级别的人员可以访问某些制造商,并且只能访问这些制造商中的某些站点,并且可能只是SiteArea的某些OperatingFunction.

对于频道数据会有一个请求,我们需要确保只返回或更新(取决于请求类型)允许个人影响的数据.

在初步调查时,实现它的明显选择似乎是QueryInterceptors和ChangeInterceptors,这意味着我们可以根据请求中发送的声明添加更多过滤器首选项.然而,看起来Query/ChangeInterceptors是Wcf的一部分,而不是WebApi,并且最重要的是它们只是v1-3 Wcf OData实现的一部分,到目前为止OData v4没有任何内容.

当然,我们可以将过滤器代码编写到每个方法中,但实际上这似乎是一种令人讨厌的方式来实现一些本质上是交叉问题的东西.

我们已经查看了EF6拦截器,但得出的结论是它们离堆栈太远了,理想情况下我们不想处理SQL命令代码本身.

我们已经简要地考虑过我们是否应该使用基于角色/任务的授权模式,并得出一个可靠的结论,即这对我们不起作用,因为它对未来的发展太过限制,并且不适用于我们的扩展计划.

基本上我们得出结论,我们需要实现我们自己的QueryInterceptorAttribute但是认为在尝试重新发明轮子之前我们是否错过了一些东西.

谢谢.

编辑:我忘了提到另一个选项可能是看看使用Decorator模式,我们使用Unity,并且可以添加我们需要的功能:Unity拦截

Answer 1

我沿着这条路走下去QueryInterceptor，发现它只不过是一个无底的抽象深渊。我无法在任何地方找到一个钩子，其中的东西a）可破译和/或b）不是只读的。

请阅读 Thinktecture 的 Dominick Baier 撰写的这篇文章。
http://leastprivilege.com/2014/06/24/resourceaction-based-authorization-for-owin-and-mvc-and-web-api/

我正在使用这种基于声明的资源/操作授权模型，效果非常好。我还建议查看 Dominick 在 Pluralsight 上的教程。他们给了我很大帮助。