API網關如何發展：更輕、更智能、云原生
當銷售代表調用系統檢索訂單信息時，系統會評估他們是否具有必要的權限。如果我們使用 ABAC，我們可以根據這些特定屬性定義規則來接受或拒絕請求。例如，可能只有admin_level3 或以上的用戶才被允許查看訂單詳細信息。此外，與該字段相關的規則user_id可以確保銷售代表只能查看與他們分配的客戶相關的訂單。
此類屬性也可以自動分配，以遵循組織的行為。例如，假設銷售代表創建了一個新用戶。系統會使用與created_by銷售代表相匹配的字段來更新此新客戶資料，從而將此客戶綁定到特定銷售代表的帳戶，并防止未經授權的用戶訪問。
user {
user_id: 00918;
created_by: 123;
orderPlaced: yes;
}更進一步，我們可以將銷售代表的用戶 ID 添加到每個訂單號前面，如下所示：
orderID {
orderNumber: $incrementOrder;
prepend: created_by;
}這將為該用戶下達的與銷售代表關聯的訂單生成一個類似于“123-00011”的訂單號。從這里，我們可以確保銷售代表只能訪問帶有此前綴值的訂單，而不能查看與其他銷售代表關聯的訂單。
這消除了一個客戶訪問另一個客戶的訂單的風險，而 RBAC 可能無法很好地處理這種風險。它還提供了一種動態調整特定權限的方法，并避免了角色爆炸的可能性。
現在我們已經了解了 ABAC 是什么樣子的，讓我們看看在為 API 設計 ABAC 時應該考慮哪些設計因素。
由于我們所有的控制權都掌握在屬性本身，而不是與這些屬性交互的用戶手中，因此 API 提供商應該認真考慮應該使用哪些具體屬性。與角色不同，角色由組織結構和與系統交互的人員的實際情況明確設定，而屬性則更加不透明。它們很大程度上取決于提供商的發現。
安全數據
尋求基本訪問控制的 API（尤其是處理少量數據的 API）不應僅僅因為存在工具就將 ABAC 視為構建高度詳細系統的機會。對于錘子來說，所有東西看起來都像釘子 — 提供商應考慮保護其服務所需的最少屬性，并從這種理解出發開始設置其安全態勢。
授權流程應允許客戶端檢索帶有屬性的訪問令牌并將其發送到 API。例如，當用戶發送請求時，客戶端會將用戶重定向到身份系統進行身份驗證，并發出包含屬性的令牌。然后，該令牌將發送到 API。然后，API 會驗證來自身份系統的令牌，信任它們并使用它們的屬性。下圖描述了這種情況。
使用令牌進行基于屬性的訪問控制的授權流程。
同樣，應該有一個通過屬性更新和超時來撤銷訪問權限的計劃。屬性不是永久的，就像授權流程一樣，應該可以隨著需求和訪問級別的變化而被撤銷或更新。因此，重要的是不僅要考慮在給定屬性的情況下，流程現在是什么樣子，還要考慮它們可能是什么樣子，以及提供商如何控制這些屬性來控制這樣的環境。
特定的架構風格，例如 GraphQL
最終，屬性將成為控制 ABAC 方法的核心系統，因此，應以與密鑰或令牌相同的安全姿態和考慮來對待屬性 – 這包括充足的靜態和傳輸加密、跟蹤屬性、采用合理的棄用模式等。實現這樣的架構需要采用靈活而強大的集成解決方案。
值得慶幸的是，OAuth 2.0等解決方案是強大的訪問控制解決方案，允許大規模高水平的控制和效率，使得 ABAC 的采用相對容易上手。
ABAC是一種比 RBAC 更強大的方法，在可擴展性和可伸縮性方面具有顯著優勢。然而，采用 ABAC 確實需要更大的分離度和更復雜的流程。對于某些 API，這可能過于復雜，帶來管理問題，而且具有諷刺意味的是，由于管理復雜且需要跟蹤更大的系統，它本身也存在擴展問題。
然而，通過充分的規劃，并結合跟蹤、更新、撤銷和棄用計劃，ABAC 確實可以用來構建一個非常安全的系統。
原文地址：https://nordicapis.com/how-to-implement-attribute-based-access-control-for-apis/
