3

我對靈活,合理粒度的安全系統有着廣泛的要求,允許我們自定義給定角色或用戶在系統內允許執行的操作。面對這個需求,我必須選擇安全體系結構中應該使用哪些對象,類或項目作爲其構建塊 - 例如,如果我們授予訪問X的角色,那麼X是什麼?一個實體,一個控制器動作,物體等的自定義列表中的項目如何在MVC + DDD + Repository Pattern項目中應用安全性?

選項我正在考慮。

1)格蘭特通過對實體CRUD操作(例如,用戶可能被授予創建/讀取/更新賬戶實體的訪問權限,以及對發票實體的讀訪問等)

2)通過對實體的CRUD操作授予的權利,對單個實體屬性(例如,訪問更新特定字段)的RU操作 - 可以被簡化與實體屬性標識的「財產組」

3)通過存儲庫授予&存儲庫功能(例如,允許呼叫AccountsRepository.Get(...)或AccountsRepository.GetList(...)等)

4)通過MVC控制器+行動授予(例如允許訪問/帳戶/索引或/帳戶/更新/ X等)

5)格蘭特通過可以在架構

選項(5)給出了最大的靈活性,但至少通用的實現內被捆綁到任意事物「安全對象」的自定義列表。選項(4)具有吸引力,因爲安全項目將密切反映用戶界面,但意味着該域不能保護訪問,並且安全性不會應用於非Web界面。

您的意見&在MVC + DDD + Repository模式中設計安全模式的經驗?

回答

1

最常見的安全機制只需要角色和資源。在這種情況下,Option(4)似乎是我見過的最常見的解決方案,因此您的平臺上應該有一些成熟的安全框架。

如果安全粒度位於域對象上,則安全性事物無法混合到域模型中。我認爲這通常是不必要的。

另一方面,某些安全需求需要業務環境,例如,一個運營商不能在超過1000美元的時間內操縱交易,而他的主管可以。 Honeslty,我沒有說明如何實現這一點,但我個人更喜歡在覈心域的另一個有界的上下文中構建安全實現。

+0

我很好奇域實體級安全性的不成功率。這對我來說似乎是默認的選擇,因爲域應該與UI無關,並且安全性不是UI級別的功能......(否則您的UI開發人員可能無法構建不安全的頁面) –

2

無論DDD,存儲庫,MVC,CQRS,[插入當天的任何趨勢],設計授權都是相同的。

您希望在發生操作(與控制器操作無關)時完成安全檢查。您檢查用戶是否有權在特定上下文中執行特定操作。在你的情況下,它確實是一個控制器動作,最簡單的方法是通過一個ActionFilter(我認爲它也可以重用WebApi)。

域模型業務概念,行爲和用例,存儲庫處理持久性,讓安全性成爲它自己的層,它將關心用戶,權利和上下文。

即使在Hippoom中提到的用例中,它仍然是一個安全層問題,它將擁有自己的安全規則,類似於根據某些預定義規則驗證輸入數據的驗證層。

1

我認爲這是安全框架設計師在思考他可以在授權問題領域提供什麼設施時所問的問題之一。

我建議你看看可用於你的平臺的實際安全框架的設計或實現。

我只知道基於Java的Spring Security和Apache Shiro。

他們通常會與每一個授權要求的設施,併爲您的問題,他們可以爲您提供在粒度的各個層面的解決方案:

  • 資源的水平(如果您有沒有興趣在哪一個對象實例應用安全檢查);
  • 實例級別(您控制對對象的特定實例的訪問);
  • 屬性級別(您可以控制對特定對象實例的特定字段的訪問)。
相關問題