在MVC + DDD + Repository模式项目中，哪些方面需要应用安全性？

Question

我有一个广泛的需求，需要一个灵活、合理细致的安全系统，使我们能够在系统内自定义某个角色或用户的操作权限。

面对这个要求，我必须选择架构中哪些对象、类或项作为安全系统的构建块 - 例如，如果授予某个角色访问X的权限，则X是什么？一个实体、一个控制器动作、自定义对象列表中的一个项等等。

我正在考虑的选项：

1）按实体的 CRUD 操作授权（例如，可以授予用户对账户实体的创建/读取/更新访问权限，对发票实体的读取访问权限，等等）

2）按实体的 CRUD 操作授权，并针对单个实体属性提供 RU 操作（例如，访问更新特定字段）- 可以通过实体上的属性标识符简化为“属性组”

3）按存储库和存储库函数授权（例如，允许调用 AccountsRepository.Get(...) 或 AccountsRepository.GetList(...) 等）

4）按 MVC 控制器 + 动作授权（例如，允许访问 /Accounts/Index 或 /Accounts/Update/X 等）

5）按自定义“安全对象”列表授权，可以与架构中的任意事物相关联

选项（5）提供了最大的灵活性，但实现最不通用。选项（4）非常有吸引力，因为安全项将紧密反映用户界面，但这意味着域不会保护访问，并且在非 Web 接口中不会应用安全性。

请问您在 MVC + DDD + 存储库模式中设计安全模式的意见和经验是什么？

- Brendan Hill

Answer 1

无论是DDD，Repository，MVC，CQRS还是任何其他最新技术潮流，设计授权都是相同的。

您希望在某个动作（与控制器动作无关）发生时执行安全检查。您检查用户是否有权在特定上下文中执行某个操作。在您的情况下，这确实是一个控制器动作，最简单的方法是通过ActionFilter来实现（我认为该方法也可以与WebApi一起重复使用）。

域模型业务概念、行为和用例，存储库处理持久性，让安全性成为其自己的层，负责用户、权限和上下文。

即使在Hippoom提到的用例中，它仍然是一个安全层问题，将拥有其自己的安全规则，类似于验证层，根据预定义的规则验证输入数据。

- MikeSW

Answer 2

最常见的安全机制只需要角色和资源。在这种情况下，选项（4）似乎是我见过的最常见的解决方案，因此您的平台上应该有一些成熟的安全框架。

如果安全粒度在领域对象上，则安全事物不可避免地混入领域模型中。我认为通常是不必要的。

另一方面，一些安全需求需要业务上下文，例如，操作员不能操纵超过1000美元的交易，而他的主管可以。老实说，我没有经验如何实现这一点，但我个人更喜欢在核心领域之外构建安全实现的另一个有界上下文。

- Yugang Zhou

---

我对域实体级别安全性的不频繁使用感到好奇。鉴于域应该相当UI无关，而安全性不是UI级别的功能，这似乎是我的默认选择...（否则您的UI开发人员可能会意外地构建不安全的页面） - Brendan Hill

Answer 3

我认为这是安全框架设计者在思考他可以在授权问题领域提供哪些设施时所问的一种问题之一。
我建议您查看可用于您平台的实际安全框架的设计或实现。
我只知道基于Java的Spring Security和Apache Shiro。
它们通常提供每个授权需求的设施，并且对于您的问题，它们可以在所有粒度级别上为您提供解决方案：

• 资源级别（当您不关心应用安全检查的对象实例时）；
• 实例级别（您控制对特定对象实例的访问）；
• 属性级别（您控制对特定对象实例的特定字段的访问）。

- Enrico Sanguin