透明授權可靠性

我需要一個用於業務邏輯類中的自定義授權的設備。它必須是基於權限的系統，但我無法決定如何將授權規則應用於方法。透明授權可靠性

我首先想到的是應用自定義屬性，方法

[NeedPermission("Users", PermissionLevel.Read)] 
public IList<User> GetAllUsers() 
{ 
    // some code goes here 
}

我的商業邏輯類有接口，這樣我就可以使用，例如，團結攔截行爲，並在運行時檢查當前用戶所需的權限。如果他沒有，就拋出異常。

但現在我擔心這種方法的可靠性。

通常對統一容器注入的業務邏輯類的引用。所以沒有問題，因爲它被配置爲應用接口攔截機制。

但是如果某些開發人員會直接實例化我的業務邏輯類呢？那麼，即使當前用戶沒有權限進行某些操作，或者即使他沒有通過身份驗證，也不會應用攔截，他將能夠調用任何方法。

也有人可以改變統一的容器配置，完全關閉攔截擴展。我的授權系統再次無法工作。

我看到ASP .NET MVC使用類似的機制進行授權。授權規則僅適用於以標準方式發出請求時（IController.Execute）。我認爲這在這種情況下不是問題，因爲控制器（Web用戶）的最終用戶無法直接訪問控制器類。

在我的情況下，業務邏輯的最終用戶是開發前端的程序員，他可以有意或無意地搞砸東西 - 創建業務邏輯類的實例並調用任何方法。

你能告訴我什麼？你如何處理這類問題？

謝謝。

來源

2011-09-01 Artyom Krivokrisenko

.NET Framework支持聲明性權限驗證機制，該機制不依賴於Unity攔截或其他「外部」AOP。爲了利用這一點，您的屬性必須從System.Security.Permissions.CodeAccessSecurityAttribute繼承。包含在BCL中的System.Security.Permissions.PrincipalPermissionAttribute是使用此機制評估用戶權限的示例。如果它不適合你的需求，沒有什麼能阻止你創建自己的屬性。

來源

2011-09-01 12:17:23

感謝妮可。這是我從未聽說過的有趣功能。據我所知，我還需要創建自定義的IPrincipal實現，它不僅包含用戶名和角色列表，還包含用戶權限列表。並在堆棧頂部的某個位置初始化Thread.CurrentPrincipal。 –

我在這裏找到http://stackoverflow.com/questions/3585081/custom-codeaccesssecurityattribute，「CAS已在4.0中棄用」。在4.0中使用CodeAccessSecurityAttribute還可以嗎？ –

CLR不再爲.NET 4.0中的獨立應用程序強制執行CAS策略。但是，這並不意味着CAS已被棄用。但是，即使它是，CodeAccessSecurityAttribute也被用作非CAS權限（如PrincipalPermission）的基類，並且將繼續可用。（理想情況下，CLR應該已經識別出此機制的所有SecurityAttribute子類，這將避免在爲非CAS權限創建屬性時產生混淆，但我們必須忍受我們所擁有的...） –

如果您的構造函數是內部的，並且您的對象是從工廠實例化的，則開發人員將無法繞過錯誤的安全性。

如果真的有人真的想在沒有安全措施的情況下創建自己的物品，他仍然可以使用反射來實現，但這樣做可能是非常有意的。

來源

2011-09-01 13:43:22 Martin

我想過這個。但是恐怕會讓統一容器配置變得複雜 –

看一下：http://www.pnpguidance.net/post/RegisteringFactoryMethodCreateObjectsUnityStaticFactoryExtension.aspx，與內部構造函數建立統一可能相對容易。 – Martin

無論如何，這仍然很難配置:) –

透明授權可靠性

回答

相關問題