问与答 安全性-域驱动设计中的访问控制

dean · 2020-02-22 20:00:06 · 热度: 15

我阅读了有关DDD和访问控制的信息,发现以下两种观点之间存在一些矛盾:

  • “安全问题应在域外处理”
  • “访问控制要求是特定于域的”

我正在寻找关于此的最佳实践。 那么我应该把域控制设计的访问控制逻辑放在哪里,应该如何实现呢?

(通过DDD + CQRS + ES来更具体地说明。)

我认为它应该接近业务逻辑,例如,一个用户故事可能是这样的:

用户可以通过发送用户名,兴趣爱好列表,简历等来编辑其个人资料...

根据用户故事,我们实现域模型和服务,例如:

UserService
    editProfile(EditUserProfileCommand command)
        User user = userRepository.getOneById(command.id)
        user.changeName(command.name)
        user.changeHobbies(command.hobbies)
        user.changeCV(command.cv)

UserRepository
    User getOneById(id)

User
    changeName(String name)
    changeHobbies(String[] hobbies)
    changeCV(String cv)

没关系,但是故事的HIS profile在哪里?

显然,这是基于属性的访问控制,因为我们应该编写如下规则:

deny all, but if subject.id = resource.owner.id then grant access

但是我们应该在哪里执行该规则,以及应该如何执行呢?

猜你喜欢:
共收到 1 条回复
tylique #1 · 2020-02-22 20:00:06

那么我应该在哪里放置访问控制逻辑呢?

据此:[https://softwareengineering.stackexchange.com/a/71883/65755]策略执行点应该在2683fraicfv8a2zuisbkcaac调用之前。

我得出了相同的结论:它不能出现在UI中,因为通过多个UI,我们将有代码重复。 应该在域事件创建之前,因为它们表明我们已经在系统中完成了某些工作。 因此,我们可以限制对域对象或使用这些域对象的服务的访问。 通过CQRS,我们不必通过读取模型拥有域对象,而仅需要服务,因此,如果需要通用的解决方案,就必须限制对服务的访问。 我们可以将访问决策放在每个服务操作的开始,但是那将是2683fraicfv8a2zuisbkcaac安全反模式。

我应该如何实施?

这取决于适合该域的访问控制模型,因此取决于用户情况。 根据访问决策,我们通常会发送访问请求并等待获得许可。 访问请求通常包括以下部分:主题,资源,操作,环境。 因此,主题需要权限才能在环境中对资源执行操作。 首先,我们确定主题,然后进行身份验证,然后是授权,然后在授权中检查访问请求是否适合我们的访问策略。 每个访问控制模型的工作方式都相似。 Ofc。 他们可能缺少其中一些步骤,但这没关系...

我创建了访问控制模型的简短列表。 我将规则和策略放入批注中,但是如果我们要拥有一个易于维护的系统,通常我们应该将它们以XACML格式存储在数据库中。

  • 通过基于身份的访问控制(IBAC),我们具有一个身份-权限存储(访问控制列表,功能列表,访问控制矩阵)。 因此,例如,通过访问控制列表,我们存储可以拥有权限的用户或组的列表。

    2683fraicfv8a2zuisbkcaac
  • 通过基于格的访问控制(LBAC),主题具有清除级别,资源具有所需的清除级别,然后我们检查哪个级别更高...

    2683fraicfv8a2zuisbkcaac
  • 通过基于角色的访问控制(RBAC),我们定义了主体角色,并授予了扮演实际角色的主体权限。

    2683fraicfv8a2zuisbkcaac
  • 通过基于属性的访问控制(ABAC),我们定义主题,资源和环境属性,并基于这些属性编写策略。

    2683fraicfv8a2zuisbkcaac
  • 通过基于策略的访问控制(PBAC),我们不会将策略分配给其他任何策略,它们是独立的。

    2683fraicfv8a2zuisbkcaac
  • 通过风险适应性访问控制(RAdAC),我们的决定基于受试者的相对风险特征和手术的风险水平。 我认为这不能用规则来描述。 我不确定其实现,也许这就是其点系统使用stackoverflow的原因。

  • 通过基于授权的访问控制(ZBAC),我们不进行身份验证和身份验证,而是为身份验证因素分配权限。 例如,如果有人发送令牌,则她可以访问服务。 其他所有内容均与先前的解决方案相似。 例如,ABAC:

    2683fraicfv8a2zuisbkcaac

    因此,每个知道2683fraicfv8a2zuisbkcaac令牌的人都可以使用该服务。

等等...

还有许多其他型号,最合适的选择始终取决于客户的需求。

所以总结一下

- "security concerns should be handled outside the domain"
- "access control requirements are domain specific"

两者都是正确的,因为安全性不是域模型的一部分,但是其实现取决于域模型和应用程序逻辑。

2年后编辑2016-09-05

由于我作为DDD新手回答了自己的问题,因此我阅读了Vaughn Vernon的《实现域驱动设计》。 这是一本有趣的书。 这是它的引文:

这构成了一个新的有界上下文-身份和访问   上下文-并将通过标准被其他有界上下文使用   DDD集成技术。 对于消费环境,身份和   访问上下文是一个通用子域。 产品将被命名   IdOvation。

因此,根据弗农说,可能是将访问控制移至通用子域的最佳解决方案。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册