将授权放入服务层而不是Web API层

时间:2017-09-25 03:25:57

标签: .net security asp.net-web-api asp.net-core authorization

我正在使用.NET Core Web API构建REST API。

我的控制器只是将请求转发到服务层并返回结果

[HttpPost(nameof(Create))]
public async Task<Response<ProviderDTO>> Create([FromBody] ProviderDTO provider)
    => await providerService.CreateAsync(provider);

我现在正处于系统中我需要开始实施授权的地步。

.NET Core有a lot of options来实现授权,但文档主要在Web层(控制器显然存在)的上下文中讨论这些方法。

我的直觉告诉我,我需要在服务层本身内实施授权,而不是将此授权放在网络层上。

我的一些推理包括:

  1. 服务层可以通过控制器以外的其他方式调用(例如,调用其他服务的服务,在授权时不会关注这一点。)
  2. 服务授权可以直接进行单元测试,而不必依赖为服务前面的每个“层”编写的集成测试。
  3. 保存对数据库的多个调用 - 如果我需要在授权要求中授权文档,如果它已通过,那么我必须在服务的后期提取相同的文档。
  4. 问题一

    IPrincipalIAuthorizationService注入我的服务并直接在那里处理授权是否合理?然后,网络层将完全检查用户是否已登录,并且可能是一些更简单的基于策略的属性(例如,此控制器仅允许员工策略)

    问题二

    有没有人有任何可以链接我的资源(我做了研究,但这里的内容并不多)

    PS:关于拒绝服务层中的请求,我有一个异常处理中间件,可以将自定义异常转换为HTTP响应。因此,如果发生未经授权的请求,我将抛出一些未经授权的异常,最终将导致HTTP 403。

1 个答案:

答案 0 :(得分:0)

这完全取决于我们所谈论的授权类型以及实现这些授权所涉及的工作量。

一般来说,将服务层与网络层混合起来并不是一个好主意,因此请将它们分开。

Web授权是一回事 - 在这里你说我有一个用户,他是否可以访问这个端点/页面/无论如何。如果不是这样,您甚至根本不调用服务层就可以节省资源,并且可以在过程的早期拒绝Web层中的请求,并且可以非常快速地浪费资源。

接下来,您正在谈论的是什么服务层?它是实际与数据库对话的那个,还是从数据层获得数据后进行数据操作的那个?

我的偏好是拥有一个单独的数据层和授权层。授权层是应用您需要的任何规则的那个,然后返回它的结果,以便您知道是否甚至无法获取任何数据。它没有链接到您的Web层,它不返回HTTP代码,一般来说与UI方面没有任何关系。

这意味着如果您有多个客户端,例如Web UI和移动UI,则两者都将通过此层,因此不会重复此级别的工作。

更好的是,您可能希望构建一个负责返回数据的合适API,然后您需要做的就是从您拥有的任何客户端处理这一件事,并且您可以在那里处理您的授权。如果您确保可以将其授权层与其他任何内容分开调用,而不依赖于其他任何内容,那么您可以从多个位置调用它,并可以轻松独立地进行测试。

这是人们在构建任何东西之前所考虑的事情,一旦完成其他任务,安全性就不是你添加的最后一件事。在构建产品时,请记住它,因为它涉及很多事情,它会影响您的架构。

一切如何融合在一起的图表会有所帮助。

  • 你有什么样的建筑?
  • 您正在谈论的授权涉及多少?
  • 我们在谈论什么样的客户?

在此之前需要回答很多很多问题。

离我只有几点,你做了几个陈述:

  

服务层可能被控制器以外的其他东西调用   (例如,调用其他服务的服务,这不是   在这一点上与授权有关。)

     

服务授权可以直接进行单元测试,而不是具有   依赖为每个“层”编写的集成测试   在服务面前。

  1. 如果您正在考虑微服务,也就是许多独立运行的小服务,那么您肯定需要关注自己的安全性,具体取决于这些内容是如何被访问和相互通信的。

  2. 这就是你写一个授权层的原因,一切都经过它,这就是你在不关心任何UI类型的情况下测试的那个。