在ASP.NET MVC應用程序中完全自定義的認證/授權..好或壞主意？

Question

我知道你已經在說（BAAD想法），但請先閱讀:)

我正在開發基於ASP.NET MVC應用程序，這將需要一些特定的功能：

1. 的組合「本地」用戶和Facebook連接登錄，但FB用戶將「鏡像」到某種本地表示，因爲會有一些統計數據和其他需要保留的兩種類型的內容

2. 授權將爲3層而不是asp.net標準的2層。我的意思是：用戶在組（m：n）和組在角色（m：n）中，而不是用戶在角色（m：n）中。

所以，如果我想使用標準認證/ authhorization方法，我將不得不：

1. 實現自定義的成員提供者，它不會甚至是「正確的」，因爲它會利用像AddUserToGroup和AssignRoleForGroup等

2. 方法來實現自定義的主/身份來訪問我自己的用戶着想對象

3. 鑄造HttpContext.User中的每一個所需要的時間我的對象......

4. 實現自定義角色提供sessting AuthCookie（在用戶數據唯一的用戶ID的

5. 自定義機制，斜面依靠第三方FB用戶的用戶名系統）

6. ...（你一定能想到的其他東西）

嗯，我真的不喜歡「彎曲」和更換每一個部分變得相當的想法凌亂的解決方案。所以我想實現我自己的機制封裝在一個地方 - 讓我們稱之爲AuthService。

1. AuthService將是線程安全的單
2. 相反AuthCookie的將使用標準的Session對象（我​​知道會議還使用cookie，但我真的沒有看到優勢的低層次存儲（餅乾）在會議上）
3. AuthService將提供AuthService.CurrentUser（我自己的類型），從會議填充每個請求的開始（Application_AuthenticateRequest，我認爲）
4. AuthService會在一個地方提供的所有方法 - 的ValidateUser，RolesForUser，IsInRole，註銷，等等

那麼現在..爲什麼我不應該這樣做呢？ :)

我認爲會話對AuthCookie同樣安全（門票和authcookie的風險相同）。 我沒有真正尋找「模塊化」（即插即用角色提供商，會員提供商，個人資料提供商..） - 我在這裏處理非常具體的東西，我不期望標準組件適合..有「我的方法」有任何其他缺點？

感謝所有好的想法和對不起我的可怕的英語，我是來自非英語國家:)

R.

Answer 1

我當然明白爲什麼你不希望實現一個完整的會員提供商。但是，我將利用Forms Authentication提供的低級支持（例如，cookie，到期等），並只進行我自己的自定義驗證。如果你這樣做，你可以將自己的自定義用戶類注入到HTTP上下文中並在整個代碼中使用它。您的自定義用戶對象將實現IIdentity和IPrincipal。您的IPrincipal.IsInRole將對您的自定義身份驗證方案起作用。這將允許您的更高級別的代碼使用標準的.NET框架權限。這是在利用已有內容的同時完成你想要的最簡單，最簡單的方法。