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

Question

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

让我们尝试决定，它是进入业务层还是位于服务层。

考虑到服务层有一个经典的远程外观接口，在这里进行权限检查似乎是必不可少的，因为用户对象实例总是在这里（服务会话绑定到用户）并准备好进行.hasPermission(...) 调用。但这看起来像是业务逻辑泄漏。

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

有什么建议可以克服这种权衡，或者您知道唯一真正的解决方案吗？

Answer 1

我认为这个问题的答案很复杂，值得在早期考虑一下。以下是一些准则。

服务层是一个好地方：

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

业务层是一个很好的地方：

• 此特定用户是否有权访问请求的记录？例如，用户应该有权访问他们的个人资料，但不能访问其他人的个人资料。
• 审核请求。业务层最适合描述请求的细节，因为此时协议和其他细节已经被过滤掉了。您可以根据您设置政策的业务实体进行审核。

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

要记住的一些想法：

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

希望这会有所帮助。