的OData的WebAPI 2複雜的授權

Question

我們有我們需要實現相當複雜的管理權限的網絡API 2的OData v3的服務。我們在客戶端代碼中使用Breeze，當發佈OData v4版本的Breeze時，我們正在將API升級到OData v4，因此該解決方案需要能夠在兩個OData版本上運行。

該圖給出的排序實體模型，我們正在與（對不起，沒有足夠的信譽分的圖像）的一個非常基本的觀點：

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

一個站點區域有「OperatingFunction」屬性 - 這顯示了在該地點區域的製造過程的哪個階段。

使用者可能

• 一個人坐在生產商級別，並且可以訪問所有的網站數據
• 一個人坐在製造水平，並已獲得了一些，但不是所有的SiteAreas的，因此，只有他們的站點區域數據
• 一個人坐在誰有權訪問一些廠家ServiceCompany水平，並在只有那些製造商中的某些網站，也許只有一個站點區域的某些OperatingFunctions的小節。

的請求會在通道數據，我們需要確保只返回或更新（取決於請求類型）的個人不得影響數據。

經初步調查爲實現這個顯而易見的選擇似乎是QueryInterceptors和ChangeInterceptors，這意味着我們可以添加基於正在發送的權利與請求進一步過濾偏好。然而，Query/ChangeInterceptors似乎是Wcf的一部分，而不是WebApi，除此之外，它們只是v1-3 Wcf OData實現的一部分，到目前爲止還沒有任何OData v4。

我們當然可以，寫一個過濾器的代碼爲每一種方法，但真的好像它是實施東西，本質上是一個橫切關注點一個討厭的方式。

我們已經看過EF6攔截器，但得出的結論是它們距離堆棧太遠，理想情況下我們不想處理SQL命令代碼本身。

我們已經簡要地考慮過我們是否應該使用基於角色/任務的授權模式，並得出了一個可靠的結論：這對我們來說不起作用，因爲它對於未來的開發來說過於狹隘，並且不適用於我們的擴展計劃。

從本質上講，我們來，我們需要實現我們自己的QueryInterceptorAttribute但認爲它值得一問，如果我們試圖另起爐竈之前錯過了一些結論。

謝謝。

編輯：我忘了提，另一個選擇可能是看使用Decorator模式，我們用團結，並與可能增加我們需要的功能：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/

我正在使用這種基於聲明的資源/操作授權模型，效果很好。我還建議查看Dominick在Pluralsight上的教程。他們幫了我很多。