您正在使用哪種認證和授權方案 - 爲什麼？

我們已經開始設計一系列新的服務來創建（WCF，ADO.NET數據服務，可能在某些時候在雲端），並且彈出的一個問題是要使用的認證和授權方案 - 有很少幾個！您正在使用哪種認證和授權方案 - 爲什麼？

我們基本上需要能夠識別各種協議（HTTP，HTTPS，TCP）上的用戶（實際人員和「虛擬」應用/服務用戶），並且我們需要爲他們分配至少一堆角色/許可查看某些數據和/或執行某些操作。

我們絕對不能單獨使用Windows羣組成員資格 - 我們有很多外部消費者使用我們的服務，我們不希望爲每個人在我們的內部域中設置域帳戶。

因此，有主要的三個選項，我認爲：

使用ASP.NET成員資格系統 - 創建用戶並分配角色有
AzMan的使用（授權管理器），這似乎是一個更精細，更成熟，更復雜的系統（與用戶，任務組 - 三個層面，而不僅僅是用戶+角色）
輥我們自己

首先 - 這三個的你會RECOM修補？任何爲什麼？

其次 - 有更多的選項，我錯過了？

感謝任何提示，指針，意見！

馬克

PS：看到答案爲止，我在鄉親選項＃3的投票量讚歎不已。我本以爲MS能夠設計出可以處理所有這些要求的可重複使用的東西......

來源

2009-04-16 marc_s

其實，答案很可能是與1相結合3.

你可以採取很多的工具的優勢和特點，框架通過編寫membership，role或profile供應商爲您提供如果默認選項沒有達到您想要的程度。

我們在很多客戶端網站上都做了這樣的事情 - 例如我們的客戶之一將大部分用戶存儲爲Commerce Server用戶，並使用Commerce Server配置文件系統，因此我們編寫了會員和配置文件提供程序與那些數據存儲進行交流 - 這是一個相當簡單的練習。

大多數人可能會爲3，因爲需要通過原始TCP進行身份驗證 - 這引起了超出標準ASP.NET會員提供一層。

大部分什麼MS產品是「OK」或「足夠好」，但總是會有優勢的情況下，你想要做的事「不太標準」意味着你最終滾動自己。我想有一些超越「基本身份驗證」或「Windows驗證」，這是簡單的爲您一般的開發人員瞭解，他們採取了「讓剛剛建立這個用於Web」的明智的選擇。

如果你看看衆多的方法可以對WCF服務進行身份驗證，你就會明白我的意思 - 這是設計來處理不同的傳輸機制，因此是更爲複雜的。（角色：沒有層次結構，所以你需要檢查每個可能的角色，或明確地指定每個角色給用戶;配置文件：所有存儲在一個字段中作爲逗號分離的值 - 不容易找到所有已設置值的用戶）。

來源

2009-04-16 19:14:11

Ldap有人嗎？它是免費的，跨平臺的，易於使用和遠程管理，已經橋接到其他認證方案，並綁定了更多的語言，你知道存在...

來源

2009-04-16 18:38:44 Varkhan

那我們不是跟Active Directory基本在同一個地方嗎？我們必須在LDAP中爲任何用戶（實際或虛擬）在LDAP中創建用戶帳戶，對吧？與其他選項相比，您認爲有什麼好處？ – 2009-04-16 18:40:01

此外，據我瞭解（但請糾正我，如果我錯了），LDAP實際上只處理驗證部分 - 你是誰？或者是否有一種簡單的方法將授權也納入其中？（你可以以用戶身份執行什麼操作？） – 2009-04-16 18:43:52

ASP.NET成員是否也爲AD集成提供了一個選項？例如，Ldap允許數據源位於Novell或Linux系統上，而在這些系統上模擬AD將很難 - 如果甚至有可能100％匹配。 – Sascha 2009-04-16 18:45:22

我們使用（3）。其實，幫助我們在集成的風景有同步賬戶

業務流程
其他系統（不是所有的相同的技術堆棧（ASP.NET））

來源

2009-04-16 18:42:48 Sascha

是不是從2003年AZMan？

我會推薦1或3.就個人而言，我總是爲3.有很多功能，我有1，我不使用或照顧使用。

來源

2009-04-16 18:44:05 Keltex

我會遠離AzMan。我們沿着這條路走了一次，不喜歡我們城鎮的一部分。我們一直在做基於AD的登錄，它們使用當前用戶的SID鏈接到數據庫中的用戶，然後獲得權限從那裏。鑑於你的設置，這可能是不可能的（或實際），但在任何情況下，我都會遠離AzMan。

來源

2009-04-16 18:46:15

我不是ASP或.NET開發人員，但我的直覺說（3）。您真的不希望公共用途的網絡應用程序能夠訪問您的公司網絡，更不用說可以將身份驗證憑據放在AD附近的任何地方。

來源

2009-04-16 18:58:33

你似乎提供太多和可擴展的堅持一個技術解決方案

解決方案3.

我將基地附近一個User類的整個應用程序你會只是單純地需要這麼模擬它會爲你提供必要的靈活性和可擴展性

喜歡的東西：

[ClassAttribute ("Yordan Georgiev", "1.0.2", "20090302", "20090415" , false)] 
public class User 
{ 
    #region DomainName 
    private string _DomainName; 
    public string DomainName 
    { 
     get { return _DomainName; } 
     set { _DomainName = value; } 
    } //eof property DomainName 


    #endregion DomainName 

    #region Status 
    private int _Status; 
    public int Status 
    { 
     get { return _Status; } 
     set { _Status = value; } 
    } //eof property Status 


    #endregion Status 

#region Password 
    private string _Password = Resources.GV.Pass; 
    public string Password 
    { 
     get { return _Password; } 
     set { 
      _Password = GenApp.Utils.Security.Encryptor.Encrypt (value, 
       GenApp.Conf.GenAppSettings.Instance.EncryptionAlgorithm); 
      //debug_Password = value; //unencrypted 
     } 
    } //eof property Password 


    #endregion Password 

#region ListUserRoles 
     private List<UserRole> _ListUserRoles; 
     public List<UserRole> ListUserRoles { get { return _ListUserRoles; } set  { _ListUserRoles = value; } } 
     #endregion ListUserRoles 


    #region UserSettings 
    private GenApp.Conf.UserSettings _UserSettings; 
    public GenApp.Conf.UserSettings UserSettings 
    { 
     get { 
      if (_UserSettings == null) 
       _UserSettings = (GenApp.Conf.UserSettings)GenApp.Conf.GenAppSettings.Instance; 

      return _UserSettings; 
     } 
     set { _UserSettings = value; } 
    } //eof property UserSettings

}

來源

2009-04-16 19:01:19

在最近的一個項目中，我們擴展了ASP.NET成員資格提供（寫了一個定製提供商）利用一些管理權限的基於角色的控制的意圖。現在項目已經成熟到足夠了，我們發現這些控件對於我們的需求來說不夠靈活，並且在某種程度上我們對MS成員的路徑感到後悔。如果您有時間正確構建它，那麼滾動您自己的身份驗證將是最佳選擇。

聽起來你的應用程序有點混合，因爲你正在爲內部和外部客戶提供服務，但也許還需要考慮爲外部客戶集成OpenID。有一些很棒的ASP.NET OpenID控件確實可以讓外部客戶處理新帳戶。這當然取決於你的申請是如何「公開」的。

來源

2009-04-16 20:41:38

您正在使用哪種認證和授權方案 - 爲什麼？

回答

相關問題