授权在分层体系结构中适合什么地方？

通常，我将授权决策放置在服务器端控制器中。这些最近是RESTful端点，但我认为MVC类型架构也是如此。为了争论起见，假设它是基于角色的授权。将对受保护的方法进行注释，或者进行检查并在必要时返回403s。

现在，考虑到授权实际上是一条业务规则-例如，“只有管理员可以列出X”，我认为应该将它们推到下一层。当控制器要求业务层执行操作时，服务或业务层会通知控制器未经授权。

这是合理的方法吗？这有缺点吗？

我不愿意拥有一个AuthorizationService，该服务本质上包含一堆静态过程编码规则来执行此操作，但是将所有访问逻辑都放在一个地方也许很有意义。是否应该将跨领域关注点分开？

因此，我想问是否有人做到这一点，以及他们如何以一种干净的方式实现它，或者是否有我可以阅读的好资源。我正在使用Java fwiw，但这是一个与语言无关的问题。

我已经在这里检查了相关的问题，它们在地面和答案上都很薄。例如：域模型中的验证和授权，并将其通过服务层传送到MVC

我正在阅读Spring安全文档，这些文档将其作为一个跨领域的关注点，因此提出了很好的论据，但是我担心这只是“春天的方式”，并且希望有更广阔的视野。它还将您的应用程序绑定到特定框架。

最好仅公开用户被授权的选项。

这迫使授权成为一个交叉问题。“视图”需要知道允许用户执行的操作，然后才能构建用于显示的选项和菜单。

后端不应信任前端来做出安全性决策，因此必须检查授权本身。

可能存在根据数据影响授权的业务规则，例如“只有余额超过$ 5000的用户才能调用外币转账”或“只有总部的用户才能查看这些帐户”。因此，业务逻辑中需要一些授权逻辑。

还需要考虑技术授权-允许谁查看日志，谁可以备份/还原数据库等。

因此，最后您的每个组件都可能有一些特定的安全性和/或授权要求，实际上，几乎不可能将其包装到单独的“授权层”中。

我认为在服务层中建立授权是绝对合理的方法。您需要保护您的服务免于执行未经授权的活动（尤其是数据修改）。您的Service层可以驻留在一个库中，并由不同的Presentation层使用（您可以具有使用同一Service层的不同UI应用程序）。而且，您不能依靠特定的Presentation层执行必要的验证这一事实。如果您随后决定将服务层移至单独的流程（例如，遵循SOA方法），则这尤其重要。

现在介绍如何以“干净的方式”实现这一目标。我不喜欢用授权检查来散布业务逻辑的想法，因此面向方面的编程方法的某些特定实现可能会有所帮助：它可以使用特殊属性来修饰服务方法，或者使用带有拦截的动态代理。

重要的是，我需要承认，在非常简单的项目中，您可能不需要单独的验证就可以生活，只是为了简化您的生活。但是重要的是不要错过“简单项目”开始成为“复杂项目”的那一刻。

我喜欢将授权检查降低到最低限度！（但没有进一步！）

您仍然可以针对“上方”的层编写自动授权测试。而且某些规则可能仅在较高的层（如服务层）中适用或有意义（CanView / CanSerialize？）。但是，我通常认为最安全的授权策略也是“ 最干燥”的策略：使用尽可能“最常见”或“共享”的代码，使授权尽可能低（而不会使auth规则复杂化）。

考虑替代方案。如果仅在服务层上测试和执行授权规则，而使不良的领域对象屈服于喜怒无常的服务对象的意愿，则通常会要求您在多个对象和多个对象中多次执行每条单独规则放置在每个对象以及更复杂的代码中。

此外，当您的分析团队聘请咨询公司使用您的域对象编写报告服务时，您就不必信任那些开发人员！（或任何其他原因。出于任何原因，您将构建其他服务或调用相同的对象。）您将不希望破解业务规则的大本领，并希望再次正确地执行这些规则。您希望您的域已经了解它们并执行它们。