Question

与我的应用程序的域逻辑一起，我试图概述安全模型。我坚持一个要求，阻止我考虑安全只是对我的域逻辑的跨领域关注。以下是我的情况。

我的系统中的用户可能会被允许创建某种对象，比如“过滤器”。我引入了一个名为“CREATE_FILTER”的权限，允许用户创建过滤器，具体取决于管理员是否为此用户分配了此类权限。确定。

现在，当用户可以创建的过滤器数量有限时，请考虑更复杂的要求。所以，例如管理员应该能够设置允许任何用户创建的过滤器的最大数量，甚至更复杂，以便为用户单独分配最大数量，例如，对User1的值为3，对User2的值为5，依此类推。因此，为了向用户授权过滤器创建，安全系统不足以检查用户是否已分配此类权限，但必须以复杂的方式分析域模型，以查看有多少过滤器已经由用户创建以做出决定。为了使事情变得更复杂，我们可以想象最大限额将取决于用户对其帐户的金额或其他内容。

我想在概念上分开（至少在我看来），这种复杂的安全逻辑是否纯粹与安全性有关（当然这取决于域模型），或者这已经是域逻辑的一个完整部分本身？保留“权限”概念是否有意义，在分配/删除权限时没有多大帮助（因为它的域状态取决于授权决策而不是分配的权限）？比如，拥有一个复杂的权限概念是不是一种方法，这种概念不仅仅是仅通过其存在的事实来允许某个行为，而是宁愿涉及一些复杂的决策逻辑？

Answer 1

这是你可以处理这个问题的一种方法......

一方面，你有一个安全模型（可能是ddd发言中的有界上下文），它解决了向主体（用户）分配权限的问题，也许通过使用角色间接解决。我会设想上边界（最大数量）是与分配的权限相关联的属性。

这个模型还有一个查询部分。然而，它只能回答“简单”的问题：

此用户是否有权创建过滤器？
此用户可以创建多少个过滤器？

有些人甚至会说这个查询部分是一个单独的模型。

另一方面，除了“用户John Doe只能创建3个过滤器”这些麻烦的要求之外，你的应用程序的模型在很大程度上是“安全”的。顺便说一句，我们现在还在谈论“用户”，而不是在这个特定用例中扮演某个角色的人，这是值得怀疑的。无论如何，回到我们如何保持这一点有点分开。假设我们有一个有点分层的方法，我们在前面有一个带有授权服务的应用服务。授权服务的职责是回答“是否允许该用户执行此操作？是或否？”如果答案是否定的，则停止处理。这是一个非常天真的版本（C＃）。

public class FilterAuthorizationServices :
  Handles<CreateFilter>
{
  public FilterAuthorizationServices(FilterRepository filterRepository) { ... }

  public void Authorize(Subject subject, CreateFilter message)
  {
    if(!subject.HasPermissionTo("CreateFilter"))
    {
      throw new NotAuthorizedException("...");
    }

    if(filterRepository.CountFiltersCreatedBy(subject.Id) > 
         subject.GetTheMaximumNumberOfFiltersAllowedToCreate()) 
    {
      throw new NotAuthorizedException("...");
    }
  }
}

注意这里甚至没有提到应用程序服务。它可以专注于调用实际的域逻辑。然而，授权服务正在使用上述模型的查询部分（由主题体现）和应用程序的模型（由FilterRepository实现）来完成授权请求。这样做是没有错的。

如果该模型可以某种方式向安全模型提供“当前创建的过滤器数量”，您甚至可以更进一步，放弃对应用程序模型的需求。但这对你来说可能是一个过于遥远的桥梁，因为这将导致评估动态表达式的路径（这不一定是一个不好的地方）。如果你想去那里，我建议你创建一个迷你DSL来定义所需的表达式和相关的代码来解析和评估它们。

如果您喜欢代理授权，您可以查看类似XACML（https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml）的内容，尽管您必须首先克服对XML的恐惧; - ）

涉及域逻辑的域安全性

1 个答案: