將授權放入服務層而不是Web API層

我正在用.NET Core Web API構建REST API。將授權放入服務層而不是Web API層

我控制器簡單地請求轉發到服務層，現在返回的結果

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

我在系統的地步，我要開始實施授權。

.NET Core有a lot of options來實現授權，但文檔主要在Web層（控制器明顯存在的地方）的上下文中討論這些方法。

我的直覺告訴我，我需要在服務層本身實現授權，而不是將此授權放在Web層上。

我的一些理由包括：

服務層可以通過比控制器以外的東西被調用（例如，服務調用其他服務，這將在不經授權點關注）。
服務授權可以直接進行單元測試，而不必依賴爲服務前面的每個「層」編寫的集成測試。
保存對數據庫的多個調用 - 如果我需要在授權要求中授權文檔（如果它通過），則必須稍後在服務中提取同一文檔。

問題一

難道是一個明智的做法注入IPrincipal和IAuthorizationService到我的服務，並在那裏直接處理授權？然後，網絡層將純粹只是檢查用戶登錄，也許有些基於簡單的策略屬性（即該控制器只允許例如工作人員的政策）

問題二

沒有人有任何的資源，他們可以通過鏈接我（我做了調查，但沒有太多的在那裏對這個）

PS：關於在服務層拒絕請求，我有一個異常處理中間件，它的自定義異常轉換成HTTP響應。因此，如果出現未經授權的請求，我會被拋出一些對未經授權的例外，這將最終導致一個HTTP的403

來源

2017-09-25 Chris

這一切都取決於什麼樣的授權，我們談論的是，有多少工作是參與決策它發生了。

一般來說，將服務層和網頁混合起來並不是一個好主意，因此請將它們分開。

Web授權是一回事 - 在這裏你說我有一個用戶，他是否允許訪問這個端點/頁面/任何。如果它們不是，那麼即使根本不調用服務層，也可以節省資源，並且可以在流程的早期階段以及在不浪費資源的情況下快速拒絕Web層中的請求。

接下來，您所談論的服務層是什麼？一旦你從數據層獲得數據，它究竟是與數據庫進行實際交談還是進行一些數據處理？

我希望有一個單獨的數據層和授權層。授權層是應用您需要的任何規則並隨後返回結果的那個層，以便您知道是否要提取任何數據。它沒有鏈接到你的web層，它不返回HTTP代碼，並且一般來說與事物的UI方面沒有任何關係。

這意味着，如果你有多個客戶端，例如像一個Web UI和移動UI則兩者都會經過這個層，這個層面的工作不重複。

更妙的是，你可能想建立負責返回數據的適當的API，那麼所有你需要做的就是應對來自任何客戶端這樣一件事，你有，你可以在那裏處理您的授權。如果你確保你可以將你的授權層與其他任何東西分開調用，而不依賴於其他任何東西，那麼你可以從多個地方調用它，並且可以輕鬆而獨立地進行測試。

這是什麼樣的事情的人想建任何東西之前，安全是不是您添加一次一切做的最後一件事。當你接觸到很多東西並且它會影響你的架構時，你會考慮它的產品。

如何將所有東西放在一起將會有所幫助。

你有什麼樣的架構？
您談論的這個授權過程如何？
我們在談論什麼樣的客戶？

有很多很多的問題需要解決在此之前可以工作。從我

只是一對夫婦更多的積分，你做了幾個聲明：

服務層可以通過比控制器其他的東西被調用（例如，服務調用其他服務，這將不在這一點上與授權有關的）。

服務授權可以直接進行單元測試，而不是讓依賴於爲服務前面的每個「層」寫入的集成測試。

如果你正在考慮微服務，其功能獨立，那麼你最肯定需要根據這些事情是如何訪問和相互通信安全擔心自己又名許多小的服務。
這就是爲什麼你寫的授權層，一切都通過它，這是你測試，而無需關心任何UI樣的事情之一。

來源

2017-09-25 08:29:42

將授權放入服務層而不是Web API層

回答

相關問題