征求意见:例如，层次安全的架构蓝图

Question

上下文

1. 一个商业市场，卖家在那里列出商品
2. 有一个操作项：：setPrice
3. 商品的销售者或客户服务代表可以改变商品的价格。
4. 第3项的安全检查是在项目的数据访问层附近实现的，以便最大限度地扩大安全检查的覆盖范围。

很多人喜欢谈论安全是一个正交的问题，但我(目前？)尤其是考虑到实例级的安全性时，尤其是考虑到这一点，因为这与域模型有着不可阻挡的联系。底线是，我实际上更喜欢在代码中显式地声明#3中的安全不变(通过代码或security注释)。我认为这种安全不变量是业务逻辑的一部分。我还想要开发商的安全。海事组织的职责并不是正交的。

我可能会写这样的东西：

@PreAuthorize("hasRole('CSR_ITEM_WRITER') or #item.seller.id == principal.id')
public void setPrice(Item item, Money price) { ... }

当涉及到安全模型的发展时，我意识到这会造成一定程度的不灵活(但考虑到错误的含义，这是件坏事吗？)

我们还讨论了CS代表必须“成为”卖家的方法。这样做有一定的清洁性(因为这实际上是将安全模型集中在域而不是用例上)。(注:将进行充分的审计，以查明某人何时代表他人行事)

意见？

Answer 1

我觉得你做得很对。当你说安全是一个正交的问题，正交什么？当您说这应该是业务逻辑的一部分时，您是对的。

我会把代表和卖家分开。这两种角色都是独特的；在这种特殊情况下，它们恰好有重叠。

在这种情况下，考虑到安全性的重要性，我希望您会编写一个sh*t单元测试风暴，这些测试演示了该选项所附带的角色的适当结果。

Answer 2

我认为你所做的是一个好主意(我目前正在做类似的事情)。

我建议您查看一下spring安全性中的PermissionEvaluator组件(请参阅这里)，因为它比普通注释有一些优点。

1. 您的安全机制可以更容易地更改，因为它更全局。
2. 安全评估可以很容易地通过审计日志/监测/.
3. 评估器实现可以进行单元测试(注释需要运行的spring上下文才能工作，因此只能在集成测试中进行测试)

到目前为止，我还没有发现这个想法的直接缺点。