在MVC + DDD + Repository模式项目中应用安全性的内容是什么？
我对灵活的、合理粒度的安全系统有广泛的需求，允许我们自定义给定的角色或用户在系统中可以执行的操作。
面对这一需求，我必须选择安全架构中的哪些对象、类或项目应该用作其构建块-例如。如果角色用户被授予访问X的权限，那么X是什么？实体、控制器动作、自定义对象列表中的项等。
我正在考虑的选项：
1)通过实体上的CRUD操作授予权限(例如，用户可以被授予对帐户实体的创建/读取/更新访问权限，以及对发票实体的读取访问权限，等等)
2)通过实体上的CRUD操作授予权限，对单个实体属性执行RU操作(例如，更新特定字段的访问权限)-可以通过实体上的属性标识的“属性组”来简化
3) Grant by Repository & Repository函数(例如允许调用AccountsRepository.Get(...)或AccountsRepository.GetList(...)等)
4)通过MVC控制器+操作授予权限(例如允许访问/Accounts/Index或/Accounts/Update/X等)
5)由“安全对象”的自定义列表授予，该列表可以绑定到体系结构中的任意内容
选项(5)提供了最大的灵活性，但最不通用的实现。选项(4)很有吸引力，因为安全项目将紧密反映用户界面，但意味着域不保护访问，并且安全性不会应用于非web界面。
在MVC + DDD + Repository模式中设计安全模式，您的看法和经验是什么？
回答 3
Stack Overflow用户
发布于 2013-10-28 04:08:50
无论DDD，REpository，MVC，CQRS，设计授权都是一样的，插入任何一天的趋势。
您希望在发生操作(与控制器操作无关)时执行安全检查。您可以检查用户是否有权在特定上下文中执行特定操作。在您的例子中，它实际上是一个控制器操作，最简单的方法是通过ActionFilter (我认为它也可以在WebApi中重用)。
域模型业务概念、行为和用例，存储库处理持久性，让安全性成为自己的层，它将关心用户、权限和上下文。
即使在Hippoom提到的用例中，它仍然是一个安全层，它将有自己的安全规则，类似于根据一些预定义的规则验证输入数据的验证层。
Stack Overflow用户
发布于 2013-10-27 20:20:15
最常见的安全机制只需要角色和资源。在这种情况下，选项(4)似乎是我见过的最常见的解决方案，因此在您的平台上应该有一些成熟的安全框架。
如果安全粒度在域对象上，则安全内容不可避免地混合到域模型中。我认为这通常是不必要的。
另一方面，一些安全需求需要业务上下文，例如，操作员不能操纵超过1000美元的交易，而他的主管可以。亲爱的，我没有关于如何实现这一点的经验，但我个人更喜欢在核心域的另一个有界上下文中构建安全实现。
Stack Overflow用户
发布于 2013-10-28 17:35:35
我认为这是安全框架设计者在考虑他可以在授权问题领域提供什么工具时问自己的问题之一。
我建议您查看适用于您的平台的实际安全框架的设计或实现。
我只知道基于Java的Spring Security和Apache Shiro。
它们通常为每个授权需求提供工具，对于您的问题，它们可以为您提供所有粒度级别的解决方案：
安全check);
- Instance资源级别(当您对应用安全级别的对象实例不感兴趣时)(您控制对object);
- Attribute级别的特定实例的访问权限(您控制对对象的特定实例的特定字段的访问权限)。
https://stackoverflow.com/questions/19616903
复制相似问题
腾讯云开发者
