Question

我们有一个Web Api 2 OData v3服务，我们需要实现相当复杂的授权。我们在客户端代码中使用Breeze，当发布ODista v4版本的Breeze时，我们将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 Interception

Answer 1

我走了QueryInterceptor路径，它只是一个无底深渊的抽象。事情是a）可辨认的和/或b）不是只读的，我找不到任何钩子。

看看Thinktecture的Dominick Baier的这篇文章 http://leastprivilege.com/2014/06/24/resourceaction-based-authorization-for-owin-and-mvc-and-web-api/

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

OData WebAPI 2复杂授权

1 个答案: