限制對記錄的訪問。基於聲明的權限是一個好主意

Question

in .net基於聲明的身份框架

如果我想限制用戶做一個操作（查看或編輯）讓我們說一個帳戶，一個特定的帳戶＃123456。（我正在談論商業實體，就像銀行賬戶一樣。）爲他們可以查看或編輯的每個賬戶創建索賠是否是一個好主意？

在集合中有很多索賠的缺點？系統管理員可能有權訪問系統中的所有帳戶，從而創建數百個索賠（對於每個帳戶可能不止一個）

Answer 1

大聲明集最直接的後果是性能較低，因爲令牌之間來回交換網絡中所有涉及的系統。例如，默認情況下，WIF將令牌序列化並將其放入Cookie中。所以在實踐中，您在這裏可以存儲的數據量也是有限的。還有其他方法可以解決這個問題，但潛在的問題仍然存在。

第二個考慮因素是您和您將在哪裏管理用戶和帳戶之間的關聯。如果這是特定於應用程序的事情，則不太可能將這些組織推送到中央STS（索賠發佈者）。您將最終使用2個STS：識別用戶（和身份提供者：IdP）的應用程序，以及特定於應用程序的STS，這些應用程序會將IdP頒發的令牌轉換爲應用程序undertsands（包括特定用戶的帳戶列表）

話雖如此，可能是用戶和他的賬戶之間的關聯是可以在許多應用程序中重複使用的東西，那麼將它放在專門的STS後面可能是有意義的。

還有第三個考慮是可能不必要地披露信息。該應用程序可能只需要知道用戶X是否有權訪問帳戶123.通過提供用戶X有權訪問的所有帳戶的列表，可以披露所需的更多信息。

作爲一般指導原則，對於「粗粒度」屬性來說更好。 「細粒度」訪問控制可能更好地在應用程序內處理，您可以使用基礎結構優化。

下面是一個極端的例子：設想一個文件系統。您是否將聲明編碼爲用戶有權訪問的文件的名稱？不太可能，因爲你最終可能會有數百萬...

另一個極端的例子：如果你想在數據庫中實現行級安全。你會爲每個用戶編碼row_id嗎？不太可能，因爲可能有很多，這是非常特定的應用程序，也因爲它可能更容易（並且更有效）用數據庫查詢解決行過濾（這是基礎結構優化的一個示例）