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

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

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

考虑到服务层有一个经典的远程facade接口，似乎有必要在这里进行权限检查，因为用户对象实例总是在这里（服务会话绑定到用户），并且可以进行

.hasPermission（…）

调用。但这看起来像是一个业务逻辑漏洞

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

---

有什么建议可以克服这种折衷，或者你知道唯一真正的解决办法吗

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

服务层是执行以下操作的好地方：

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

业务层是进行以下操作的好地方：

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

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

要记住的一些想法：

将安全性推进到框架中的次数越多越好。如果您有几十个服务调用，每个服务调用都需要在代码开头执行安全检查，那么您就是在询问一个bug（可能还有一个漏洞）。如果你有一个框架，就使用它

某些安全性最好是离网络最近。例如，如果您希望禁止向您发送垃圾邮件的IP地址，那么这绝对不应该出现在业务层。离网络连接越近，效果越好

重复安全检查不是问题（除非是性能问题）。通常情况下，在工作流中越早检测到安全问题，用户体验就越好。也就是说，您希望保护尽可能靠近实现的业务操作，以避免绕过早期安全检查的后门。这通常会导致为了UI而进行早期检查，但最终检查会在业务流程的后期进行

---

希望这能有所帮助。

如果我们在服务层应用规则，服务方法将采用用户所做的参数。例如，在mvc控制器中，我将向服务发送一个用户名为productService.Update（User.Principal.Identity.Name，product）的请求；这是真的吗？您需要用户名、用户ID或用户的其他表示形式。您还可以将其用于日志记录、审核和调试。