应用程序的哪一层应该保留安全逻辑（权限，授权）？

Question

由于最相似的问题与ASP MVC有关，我想知道一些常见的正确选择策略。

让我们尝试决定，它会进入业务层还是坐在服务层上。

考虑到服务层具有经典的远程外观接口，因此用户对象实例总是在这里（服务会话绑定到用户）并准备好.hasPermission(...)调用。但这看起来像是商业逻辑泄漏。

在业务层中实施安全检查的不同方法中，我们使用“安全令牌”参数和类似的东西来污染域对象接口。

任何建议如何克服这种权衡或者你知道唯一真正的解决方案？

Answer 1

我认为这个问题的答案很复杂，早期值得一提。以下是一些指导原则。

服务层是：

的好地方

• 页面是公开的还是只对注册用户开放？
• 此页面是否需要具有特定角色的用户？
• 身份验证过程，包括将令牌转换为用户的内部表示。
• 网络检查，例如IP和垃圾邮件过滤器。

业务层是：

的好地方

• 此特定用户是否可以访问所请求的记录？例如，用户应该可以访问他们的个人资料，但不能访问其他人的个人资料。
• 审核请求。业务层处于最佳状态以描述有关请求的细节，因为协议和其他细节已被过滤掉。您可以根据要设置策略的业务实体进行审计。

您可以将访问决策与执行点分开。例如，您的业务逻辑可以使用代码来确定用户是否可以访问特定角色并将其作为回调提供给服务层。有时候这是有道理的。

要记住一些想法：

1. 您可以将安全性推向框架越多越好。如果您有几十个服务调用，每个人都需要在代码的开头执行安全检查，那么您就是在寻找一个错误（也许是一个漏洞）。如果您有框架，请使用它。
2. 某些安全性最接近网络。例如，如果您希望禁止向您发送垃圾邮件的IP地址，那么绝对不应该在业务层中。离网络连接越近越好。
3. 复制安全检查不是问题（除非是性能问题）。通常情况下，工作流中较早的可以检测到安全问题的用户体验越好。也就是说，您希望保护业务运营尽可能接近实施，以避免绕过早期安全检查的后门。这经常导致为了UI而进行早期检查，但最终检查发生在业务流程的后期。

希望这有帮助。