在 MVC + DDD + 存储库模式项目中应用安全性的内容
本文关键字：安全性 应用 模式 DDD MVC 存储 项目 | 更新日期: 2023-09-27 18:37:10
我对灵活、合理粒度的安全系统有广泛的要求，允许我们自定义允许给定角色或用户在系统内执行的操作。
面对这个要求，我必须选择安全应该使用架构中的哪些对象、类或项作为其构建块 - 例如。 如果角色 US 授予对 X 的访问权限，那么 X 是什么？实体、控制器操作、自定义对象列表中的项等。
我正在考虑的选项：
1） 通过对实体的CRUD 操作授予（例如，可以向用户授予对帐户实体的创建/读取/更新访问权限，以及对发票实体的读取访问权限等）
2） 通过对实体的CRUD 操作授予，以及对单个实体属性的 RU 操作（例如，访问更新特定字段） - 可以使用由实体上的属性标识的"属性组"进行简化
3） 由存储库和存储库功能授予（例如，允许调用 AccountsRepository.Get（...） 或 AccountsRepository.GetList（...） 等）
4）由MVC控制器+操作授予（例如，允许访问/帐户/索引或/帐户/更新/X等）
5） 通过自定义的"安全对象"列表授予，该列表可以绑定到架构中的任意事物
备选方案（5）提供了最大的灵活性，但最不通用的实现。选项 （4） 很有吸引力，因为安全项将密切反映用户界面，但意味着域没有保护访问，并且安全性不会应用于非 Web 界面。
您有什么观点和经验在MVC + DDD + Repository模式中设计安全模式？
无论 DDD、重构、MVC、CQRS 如何，设计授权都是相同的，[插入当天的任何趋势]。
您希望在发生操作（与控制器操作无关）时执行安全检查。您检查用户是否有权在特定上下文中执行特定操作。在您的情况下，它确实是一个控制器操作，最简单的方法是通过 ActionFilter（我认为它也可以与 WebApi 重用）。
Domain对业务概念，行为和用例进行建模，存储库处理持久性，让安全性成为自己的层，它将关心用户，权限和上下文。
即使在 Hippoom 提到的用例中，它仍然是一个安全层问题，它将有自己的安全规则，类似于根据一些预定义规则验证输入数据的验证层。
最常见的安全机制只需要角色和资源。在这种情况下，选项 （4） 似乎是我见过的最常见的解决方案，因此您的平台上应该有一些成熟的 sectiry 框架。
如果安全粒度在域对象上，则安全内容将不可避免地混合到域模型中。我认为这通常是不必要的。
另一方面，一些安全要求需要业务背景，例如，操作员不能操纵超过1000美元的交易，而他的主管可以。Honeslty，我对如何实现这一点没有经验，但我个人更喜欢在核心域的另一个边界上下文中构建安全实现。
我认为这是安全框架设计师在考虑在授权问题中可以提供哪些设施时会问自己的问题之一。
我建议您查看适用于您的平台的实际安全框架的设计或实现。
我只知道基于Java的Spring Security和Apache Shiro。
它们通常附带满足每个授权要求的功能，至于您的问题，它们可以为您提供所有粒度级别的解决方案：
- 资源级别（当您对哪个对象实例不感兴趣时，请应用安全性检查）; 实例
- 级别（您可以控制对对象特定实例的访问）;
- 属性级别（控制对对象特定实例的特定字段的访问）。