3

我对灵活、合理粒度的安全系统有广泛的要求，允许我们自定义允许给定角色或用户在系统中执行的操作。

面对这个要求，我必须选择架构中的哪些对象、类或项目安全性应该用作其构建块——例如。如果我们授予一个角色访问 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 + Repository 模式中设计安全模式有什么看法和经验？

4

3 回答 3

2

无论 DDD、REpository、MVC、CQRS，[插入当天的任何趋势]，设计授权都是相同的。

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

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

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

于 2013-10-27T20:08:49.900 回答
1

我认为这是安全框架设计人员在考虑他可以在授权问题领域提供哪些设施时问自己的问题之一。

我建议您查看可用于您的平台的实际安全框架的设计或实现。

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

它们通常配备满足每个授权要求的工具，对于您的问题，它们可以为您提供所有粒度级别的解决方案：

  • 资源级别（当您对哪个对象实例应用安全检查不感兴趣时​​）；
  • 实例级别（您控制对对象的特定实例的访问）；
  • 属性级别（您控制对对象特定实例的特定字段的访问）。
于 2013-10-28T09:35:35.127 回答
1

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

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

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

于 2013-10-27T12:20:14.873 回答