我对灵活，合理细化的安全系统有广泛的要求，允许我们自定义允许给定角色或用户在系统中执行的操作。
面对这个要求，我必须选择安全性应该用作构建块的体系结构中的对象，类或项目 - 例如。如果一个角色我们授予了X的访问权限，那么什么是X？实体，控制器操作，自定义对象列表中的项目等。
我正在考虑的选项：
1）通过CRUD对实体进行授权（例如，可以授予用户对帐户实体的创建/读取/更新访问权限，以及对发票实体的读访问权等）
2）通过CRUD对实体的行动授予，对单个实体属性的RU操作（例如，访问更新特定字段） - 可以通过实体上的属性标识的“属性组”进行简化
3）由存储库授予＆amp;存储库功能（例如，允许调用AccountsRepository.Get（...）或AccountsRepository.GetList（...）等）
4）MVC Controller + Action授予（例如允许访问/ Accounts / Index或/ Accounts / Update / X等）
5）通过自定义的“安全对象”列表授予，该列表可以绑定到架构中的任意内容
选项（5）提供最大的灵活性但最不通用的实现。选项（4）很有吸引力，因为安全项将紧密反映用户界面，但意味着域不保护访问权限，并且安全性不会应用于非Web界面。
您有什么看法＆amp;体验在MVC + DDD + Repository模式中设计安全模式？
答案 0 :(得分：2)
无论DDD，REpository，MVC，CQRS，[插入当天的任何趋势]，设计授权都是相同的。
您希望在发生操作（与控制器操作无关）时执行安全检查。您检查用户是否有权在特定上下文中执行某项操作。在你的情况下，它实际上是一个控制器动作，最简单的方法是通过ActionFilter（我认为也可以在WebApi中重复使用）。
域模型业务概念，行为和用例，存储库处理持久性，让安全性成为自己的层，关注用户，权限和上下文。
即使在Hippoom提到的用例中，它仍然是一个安全层问题，它将拥有自己的安全规则，类似于根据某些预定义规则验证输入数据的验证层。
答案 1 :(得分：1)
最常见的安全机制只需要角色和资源。在这种情况下，选项（4）似乎是我见过的最常见的解决方案，因此在您的平台上应该有一些成熟的安全框架。
如果安全粒度在域对象上，则安全性不可避免地混入域模型中。我认为通常没必要。
另一方面，一些安全要求需要业务环境，例如，运营商无法操纵超过1000美元的交易，而他的主管可以。 Honeslty，我没有关于如何实现这一点的说明，但我个人更喜欢在核心域的另一个有界上下文中构建安全实现。
答案 2 :(得分：1)
我认为这是安全框架设计师在考虑授权问题所提供的设施时会问自己的一个问题。
我建议您查看适用于您的平台的实际安全框架的设计或实现。
我只知道基于Java的Spring Security和Apache Shiro。
他们通常会为每个授权要求提供设施，对于您的问题，他们可以为您提供各种粒度的解决方案：