自定義主體對象與ASP.NET中的Membership API？

我試圖獲得在傳統的ASP.NET應用程序中實現自定義授權的所有各種技術的處理 - 似乎首選的方法是通過創建自定義提供程序模型來使用Membership API。自定義主體對象與ASP.NET中的Membership API？

我有興趣實現基於角色和個人權限組合的自定義角色授權模型（角色由權限組成，用戶可以擁有多個角色或特定權限，這些角色或特定權限會覆蓋角色可能擁有的任何權限）

創建完整的角色提供者與實現自定義主體對象並在IsInRole方法的重載中實現所有授權邏輯有什麼優勢或缺點？自定義校長是否可以回溯到1.1版本？一般來說，你應該在什麼時候實施一個自定義委託人？

我們使用Active Directory作爲用戶存儲。第三方諮詢公司已經實現了基於TERRIBLE自定義角色的授權模塊，該模塊包含XML文件中包含的授權邏輯和規則，並在每個用戶的Session對象中傳遞，並且與授權的ASP.NET基礎結構無關。

我想知道這種情況的最好的做法是什麼

2011-06-22 manning18

我會建議堅持使用asp.net成員資格和角色提供程序體系結構。它集成得很好，是一個很好的思想體系。

如果您需要使用其他帳戶存儲，則可以使用asp.net成員資格或活動目錄來始終實現自定義成員資格和/或角色提供程序。這並不難。

將自定義第三方系統包裝到自定義角色提供程序中可能是可能的，但如果您有特定需求，而且在給定類中未提供，我只會自定義。

2011-06-23 07:17:15

我同意鉤住提供商模式似乎是最可靠的解決方案。在這種情況下，何時使用自定義主體對象？它們似乎與角色提供者的功能意圖有一些重疊，明顯地指定了更完整的功能集。 – manning18

@ manning18你有沒有找到答案？ –

不幸的是，沒有人給我一個明確的答案，清楚地概述和比較了兩種方法的優缺點。最後，我選擇了一個自定義角色提供程序，因爲它更易於維護，並提供了更廣泛的功能集/掛鉤來實現，並且通常看起來像是首選/「現代」方法。 – manning18

回答