Rust 應用程式的授權領域迎來了新的競爭者 Gatehouse，這是一個靈活的授權庫，因其多正規化方法和對開發者友好的設計而受到開發者的關注。該庫結合了基於角色（RBAC）、基於屬性（ABAC）和基於關係（ReBAC）的訪問控制策略，為 Rust 開發者提供了實現授權系統的綜合工具包。
Gatehouse 核心特性
- 多正規化授權：支援 RBAC、ABAC 和 ReBAC 模式
- 策略組合：使用邏輯運算子（AND、OR、NOT）組合策略
- 詳細評估追蹤：完整的決策跟蹤，用於除錯和審計
- 流暢的構建器 API：使用 PolicyBuilder 構建自定義策略
- 型別安全：強型別資源/操作/上下文
- 非同步就緒：內建 async/await 支援
內建策略
RbacPolicy：基於角色的訪問控制AbacPolicy：基於屬性的訪問控制RebacPolicy：基於關係的訪問控制
非同步優先設計引發討論
Gatehouse 的非同步友好架構已成為社群討論的焦點。該庫為策略檢查實現了非同步函式，一些開發者對此提出質疑，因為許多授權檢查本質上不需要 I/O 操作。專案維護者澄清說，這一設計選擇是經過深思熟慮的，目的是支援基於關係的授權中的圖遍歷等場景，並能夠短路昂貴的操作。
「我想支援短路機制，這樣如果策略不需要進行某些昂貴的 IO 呼叫，就可以提前返回，從而跳過這些呼叫。」
這種方法為可能需要在授權檢查期間執行資料庫查詢或服務呼叫的應用程式提供了靈活性，同時仍允許更簡單的記憶體中策略評估。這一設計選擇反映了一種前瞻性思維，允許開發者從更簡單的授權模型開始，並在不進行大量重構的情況下演變為更復雜的模型。
與基於 DSL 的替代方案的比較
評論中的許多開發者將 Gatehouse 與其他授權框架（如 Cedar）進行了比較，後者使用領域特定語言（DSL）進行策略定義。雖然 DSL 提供了跨語言相容性和將策略作為資料而非程式碼儲存的能力等優勢，但一些開發者表達了對 Gatehouse 原生 Rust 方法的讚賞。
討論突出了一個重要的權衡：基於 DSL 的系統為需要跨不同程式語言共享策略或將策略作為資料管理的組織提供了更大的靈活性，而像 Gatehouse 這樣的程式碼原生方法則為較小的專案提供了與應用程式更緊密的整合和潛在的更簡單的開發者工作流程。
資料訪問挑戰
社群討論中的一個反覆出現的主題是雙寫問題和圍繞授權決策的資料訪問挑戰。一位評論者指出，僅靠策略引擎不足以構建全面的授權系統——它們還需要訪問做出授權決策所需的資料。
這凸顯了開發者實施 Gatehouse 時的一個重要考慮因素：雖然該庫提供了靈活的策略評估，但應用程式仍需確定如何高效地檢索並向策略引擎提供必要的資料。與一些更具主見的框架不同，Gatehouse 將這一方面留給了應用程式開發者，採用了一種自帶持久化的方法，一些評論者特別欣賞這一點。
程式碼組織考慮
社群的一些技術觀察集中在庫的程式碼組織上，一位評論者注意到主庫檔案的大小較大。這引發了關於 Rust 中程式碼組織實踐的簡短討論，維護者承認拆分大檔案將是有益的。這種社群反饋展示了開源開發的協作性質，併為未來的改進提供了寶貴的意見。
總之，對於尋求靈活、原生授權解決方案的開發者來說，Gatehouse 代表了 Rust 生態系統中一個有前途的新成員。它的多正規化方法和非同步友好設計為實現複雜授權系統提供了堅實的基礎，儘管開發者需要仔細考慮如何將其與資料訪問模式整合。與許多安全相關的庫一樣，正確的選擇在很大程度上取決於特定的專案需求和組織約束。
參考：Gatehouse