為什麼許可權授權很難？- osohq

banq發表於2021-09-16

授權存在根本性的緊張關係。是業務邏輯還是授權邏輯？它應該在應用程式中，還是分開？
兩年前，我和我的聯合創始人開始為基礎設施構建安全工具。我們一直聽說應用程式開發人員正在構建自己的授權工具。起初我們有點懷疑。人們多年來一直在建立授權。這不是一個解決的問題嗎？但它一直出現。(注：我是Oso 的聯合創始人兼 CTO，Oso是一家構建應用程式授權框架的公司。)
隨著我們與更多的工程團隊會面，我們聽到了一系列的回應。
一些團隊告訴我們，“我們只花了 18 個月的時間來構建授權服務。” 其他人說，“授權是我們核心業務邏輯的一部分，我們永遠無法將其拆分。” 一些人說，“我們的要求很簡單”，而另一些人說，“我們的系統是瘋狂的定製。”
雙方都對。
當時，授權在科技圈並不是特別流行。快進到今天，Airbnb、Carta、Slack和Intuit都在撰寫有關他們構建的內部授權系統的部落格文章。突然間，授權似乎是一個和遷移到 Kubernetes 一樣酷的話題！
現在是討論授權困難的原因、解決它的一些方法以及相關權衡的好時機。這就是我將在這篇文章中介紹的內容。TL; 博士
  1. 強制執行授權很困難，因為它需要在很多地方發生。控制器、資料庫對映器、路由器和使用者介面都需要強制執行授權。因此，適用於所有情況的現成方法有限。
  2. 決策架構很難，因為您想將授權與應用程式分開，但很多授權資料也是應用程式資料。當需要做出決定時，單體可以檢查自己的資料庫，但是如果您想將授權整合到一個單獨的服務中會發生什麼？許多現成的解決方案專注於分離——協調它並保持一切同步也很有挑戰性。
  3. 建模授權也很難。想出第一個用例很容易——roles在資料庫中新增一個表可以工作一段時間。但是很難從簡單開始，然後根據需要逐漸增加複雜性。並且很難製作出易於上手的強大功能。可用的選項通常在頻譜的一端或另一端出錯。

 

三項授權
我們可以將任何授權系統分解為三個基本部分：執行、決策機制和建模。這個 Ruby 小片段包含所有三個：

unless user.admin?
  raise Forbidden, "you must be an admin to update this post"
end

  • 執行許可權

強制執行是您的應用程式對授權決定實際執行的操作。一旦您的應用決定拒絕訪問，它如何向使用者顯示？ 
執行許可權面臨的挑戰是：沒有單一的地方或單一的方法可以實現執權，從資料訪問層一直顯示到客戶端介面都有執行點。
  • 決策

授權決策回答了這個問題：是否允許使用者在此資源上執行此操作？決策由邏輯（管理員可以更新）和資料（user物件）組成。
最佳實踐是將決策邏輯與應用程式程式碼分開。但是決策資料通常由授權資料（例如使用者具有什麼角色）和應用程式資料（例如帖子的作者）組成。決策邏輯如何訪問應用程式資料？超越簡單的單體架構的任何東西都使這個問題難以回答。
  • 建模

建模是我們將授權邏輯的各個部分分組為更高階別概念的方式。例如，採用上面的程式碼片段user.admin?。這意味著Users 可以有一個被呼叫的角色admin，並且擁有該角色會授予使用者一定數量的許可權。那是一個模型！
大多數應用程式從一個簡單的授權模型開始，但隨著時間的推移變得複雜。從簡單的規則開始，然後演變為涉及關係和屬性的更細粒度的許可權是很自然的。
結果是簡單系統（易於開始，讓您快速上手）與可以處理更多複雜性(具有大量選擇並且有時學習曲線更陡峭)的系統之間存在緊張關係。

詳細點選標題

相關文章