許可權系統的基本概念和架構

flydean發表於2020-12-21

簡介

許可權系統是我們在系統設計和應用中一種非常常見的系統。一般來說許可權系統的功能分為認證和授權兩種。認證就非常簡單的,驗證完使用者名稱密碼就算認證成功,而授權裡面的套路就很多了,本文將會詳細講解許可權系統中的一些基本概念和設計上面要注意的問題,希望大家能夠喜歡。

授權流程

在授權流程中主要有三個部分,分別是資源管理,許可權和策略管理,策略的執行。

先看下資源管理:

首先我們需要建立一個資源伺服器,然後在資源伺服器中建立各種資源,最後對各種資源設定一些scope,scope就是跟資源相關的的一些可執行的操作。

什麼是資源呢?資源可以是一個web頁面,一個RESTful資源,一個檔案等等。

舉個例子,假如我們有一個圖書館資源伺服器,圖書館有一個本《人月神話》的書,那麼這本書就被稱作資源。接下來我們需要為這個資源定義一些可操作性的scope,或者說策略。比如說只有本校的學生才能夠借閱這本書。

當我們定義好資源之後,就需要對這些資源進行一些許可權和策略的設定,這就需要進行許可權和策略管理。

看下許可權和策略管理的流程:

首先是建立策略,然後定義許可權,最後將許可權和策略進行關聯。

策略就是定義的一些去訪問某些資源或者許可權的操作,策略是和具體的許可權是分離的,策略只制定了在什麼情況下可以做(某些事情),或者在某些情況下不能做(某些事情),這些事情就是後面建立的許可權。

比如說,擁有user角色可以做什麼事情,就是一種策略。

策略定義好了,我們就可以建立許可權了,許可權很好理解,比如:借《人月神話》的書的許可權。

我們把策略和許可權組合起來就是:擁有user角色的,可以借《人月神話》這本書。

通用的策略有很多種,比如說基於屬性的訪問策略,基於角色的訪問策略,基於使用者的訪問策略,基於上下文的訪問策略,基於時間的訪問策略,基於規則的訪問策略或者其他的自定義策略等。

通常來說,基於角色的訪問策略role-based access control (RBAC)是最常用的。

我們把使用者賦予相應的角色,然後在訪問資源的時候根據不同的角色策略來執行不同的permission操作。

雖然RBAC非常有用,用途也非常廣泛,但是它還是有下面的幾個缺點:

  1. 資源和角色是強繫結的,如果我們對角色進行一些新增,刪除和修改操作,將會影響到所有相關聯的資源。
  2. 對於角色的修改則可能需要我們對程式碼進行修改。
  3. 如果你的應用程式非常大的話,使用RBAC可能會出現一些錯誤。
  4. RBAC的靈活性不夠強,不能夠做到更加細粒度的許可權控制。

最後,我們看一下策略的執行。

策略的執行就是真正的在資源伺服器上執行相應的授權工作。一般來說我們在資源伺服器中有一個 Policy Enforcement Point (PEP)來和授權伺服器進行互動,根據授權伺服器返回的授權資訊來執行相應的資源操作。

許可權系統的架構

先看一張許可權系統的基本架構圖:

其中有下面幾個關鍵元件:

  • PAP全稱是Policy Administration Point,它是一個許可權管理的後臺頁面,我們需要這樣的一個後臺介面來配置和管理許可權和資源。

  • PDP全稱是Policy Decision Point,它提供了一些決策策略,通過這些策略將授權請求傳送到相應的位置,並根據請求的許可權對策略進行相應的決策。

  • PEP全稱是Policy Enforcement Point,在不同的資源伺服器中執行相應的策略。

  • PIP全稱是Policy Information Point,在判斷和決策策略的時候,可以從中獲取相應的屬性資訊。

上圖中,Storage就是資料的儲存和分類,這裡我們主要儲存resouce,scope,permission和policy這4種物件。

resource代表的是要訪問的物件,可以是一個或者多個物件的集合。比如說:web程式中的頁面等等。資源是受保護的物件,需要為資源配置一些許可權。

每個資源都有一個唯一的識別符號,可以代表一個資源或一組資源。 例如,你可以管理一個銀行帳戶資源,該資源代表並定義了所有銀行帳戶的一組授權策略。 但是,你也可以使用另一個名為Alice's Banking Account的資源,該資源代表由單個客戶擁有的單個資源,該資源可以具有自己的一組授權策略。

我們看一個resource的例子:

上圖中,我們將不同的URI定義為resource。並給不同的resource起了唯一的名字。

Scope是對資源的一系列操作,比如你可以對資源進行讀,寫或者編輯,刪除操作,這些都可以被稱之為scope。當然,你也可以指定resource中的某個屬性作為scope。

然後就是Permission,許可權將受保護的物件與是否授予訪問許可權的策略相關聯。

比如我們有下面一個許可權:

X CAN DO Y ON RESOURCE Z

x表示的是一個或者多個使用者,角色或者groups,或者是他們的組合。

Y表示的是對資源的一種操作。

Z就是資源了,比如/index頁面。

我們可以建立基於resource的permission:

也可以建立基於scope的permission:

Policy定義了要授予物件訪問許可權必須滿足的條件。Policy並沒有指明要保護的物件,只是指定了訪問給定物件必須滿足的條件。

比如上面的Policy,指定了什麼樣的角色,針對什麼樣的client,制定出來的什麼樣的邏輯。

有了策略就需要一個Policy Provider,Policy Provider主要為我們提供特定策略型別的實現。

為了做好策略評估的工作,我們還需要一個策略評估引擎,通過這個engine來執行策略的評估工作。

除此之外,作為一個認證伺服器,我們還需要對外提供認證服務,那麼最好的辦法就是提供OAuth2或者OpenID Connect的token服務。

另外我們還需要一個Protection API,用於resource server和許可權管理服務進行互動。

本文已收錄於 http://www.flydean.com/authorization-service/

最通俗的解讀,最深刻的乾貨,最簡潔的教程,眾多你不知道的小技巧等你來發現!

歡迎關注我的公眾號:「程式那些事」,懂技術,更懂你!

相關文章