1

我試圖使用Web API/OWIN/OAuth的實現基於聲明的授權設置,我試圖找出管理更加的最佳途徑細粒度的授權類型。最佳實踐使用的Web API索賠大名單/ OWIN

我不喜歡使用只是角色的想法,因爲需要有大量的在我工作的應用細粒度的授權。我認爲角色+權限方法更有意義(角色簡單地映射到權限子集)。權限將基於操作+資源對(例如,CanViewEmployee,CanEditEmployee等)。這裏沒什麼不尋常的。

不過,我想,這應該使用OWIN/OAuth的可能使用Thinktecture IdentityServer來實現。我試圖避免硬編碼自定義AuthorizationManager中的權限,因爲它們需要在不重建的情況下輕鬆更改。我知道這是一個選項,可以將這些策略放在web.config中(將資源+操作映射到聲明類型和值),但如果我們談論的是幾十甚至幾百個權限,則看起來好像它可能會得到也很快失控。

我想第三個選擇是從數據庫驅動它,但是從那裏管理它也需要某種類型的前端來執行此操作,而不僅僅是更改config/XML文件。

我丟失了一些其他的選擇/最佳做法,在這裏,當涉及到大量的索賠/權限,或者一些其他實用程序或包,我可以用它來幫助管理這個當數不可收拾?

回答

0

將這些權限解耦到單獨的授權管理器類是一個不錯的第一步。在那段代碼中,你可以硬編碼你的權限規則(比如「Admin」角色可以執行X,Y和Z操作,但只有「Manager」角色可以執行X或Y)。但是您也可以讓授權管理器中的代碼執行動態查找來檢查已在數據庫中設置的權限(例如)。

代碼這樣做的另一個好處是,你可以單元測試這一切來證明你的許可邏輯正確執行(並因此將在運行時妥善執行)。如果您的權限經常更改,這將很有用。

此外,去耦會幫助,如果你需要頻繁地重新部署(因爲頻繁變化),因爲代碼可以被分離到它自己的裝配。

+0

對,我明白,但我想弄清楚這是否是管理許多權限的最佳方式。我希望避免在代碼中做到這一點,以避免代碼混亂,並在權限(不可避免地)更改時重建,並避免有數百行代碼與規則,所以我一直傾向於在數據庫中這樣做,以便我們可以通過管理屏幕動態更改它們。我只是想確保我沒有錯過任何東西,而且那裏沒有更好的選擇。 – ChrisC 2014-10-17 15:40:55

+0

已更新,可爲頻繁更新添加單元測試和隔離功能。至於權限變化頻繁 - 很難說。也許這些應該是數據庫中的標誌而不是代碼中的標誌。 – 2014-10-17 16:58:55

+0

是的,我當然更傾向於DB。謝謝(你的)信息! – ChrisC 2014-10-17 17:54:51