我們如何在動態環境中使用基於角色的安全性？

Question

我們總是在大型系統中使用基於角色的問題。在這樣的軟件中，我們希望超級用戶能夠設置其組織用戶的權限。我們可以創建許多原子角色並創建一個控制檯來爲用戶分配角色。然後，我們必須創建多個角色，例如：

addProduct命令，RemoveProduct，EditProduct，AcceptPurchase，DenayPurchase，...

通過這種方式，對於一箇中等系統，我們應該有至少50角色！那麼管理員如何爲每個用戶分配這些角色？

我們第一眼兩個解析：

1. 要在數據庫中創建一個表（例如集團）的用戶和角色之間放。然後管理員應該創建一組角色，然後將一個組分配給多個用戶。

2. 將角色用作一組權限。例如，創建PermissionInRoles表併爲每個角色分配權限，然後將角色分配給用戶。

我們很快發現第一種方法是廢話。我們用第二種方法實施了幾個項目。但是現在我們想在除WCF RIA身份驗證服務之外的sivlerlight項目中使用它。它只是支持角色。例如，每個用戶實例都有一個IsInRole方法，我們實施我們的IsInPermission方法。

使用RequiresRole屬性進行服務時存在另一個問題。我不能，也不想爲每個服務方法設置硬編碼角色名稱。

知道我們對基於角色的安全設計感到困惑！我們如何在這些情況下使用它？

Answer 1

您對「基於角色」的授權的概念似乎有點缺陷。再一次，這並不罕見，因爲在那裏有各種各樣的定義，並不完全是暴力協議，至少在他們的更精細的細節中。他們都傾向於共同的唯一的事情是，授權嘗試通過還是失敗的主要決定因素是用戶的屬性，而不是目標是計劃執行某個操作的屬性。除此之外，如果授權系統聲稱是「基於角色」，那麼您可能不應過多地假設授權系統實際執行的操作。

例如，在您現在使用的基於ASP.NET角色的授權範例中，實際的「角色」對應於固定的（即：在編譯時已知的）一組操作。例如，您可能希望看到固定的「產品經理」角色，而不是您在原始文章中列出的粒度「AddProduct」，「RemoveProduct」和「EditProduct」權限。如果你想在更細粒度的層面進行授權，那麼這種「純粹的」基於角色的方法並不是真的適合，而且IPrincipal.IsInRole可能根本不是你應該使用的東西。

這聽起來像你想授權粒度「操作」，操作通過運行時配置分組爲「角色」。某些「管理」用戶將有權管理此配置。他們可以根據需要創建，修改和刪除「角色」，每個「角色」是由您的應用程序識別的一組「操作」（即，：「角色」是「操作」，因爲「組」是「用戶」）。您的應用程序不需要對角色有任何意識。相反，它會授權操作。用戶將通過以下任何被授予權限的操作：

1. 授予操作權限的用戶，操作權限的
2. 授予用戶屬於哪個組，角色權限的
3. 格蘭特用戶，或
4. 授予角色權限以分組給用戶所屬。

當只使用方法＃4時，授權的管理大大簡化，但用於授予權限的實際方法在執行操作之前對驗證權限的代碼應該完全沒有影響。

這類事情並不罕見，雖然對它的支持尚未構建到.NET Framework中。至少有一部分工具可以幫助您（例如：AzMan），但我並不知道.NET的任何商業框架都能提供所有必需的部分，而不需要至少一些自定義編碼。 （在這個領域有一些小型的開源項目，但是你需要在你的應用程序中評估它們的優點和缺點。）