我們正在運行使用與成千上萬的用戶受保護內容的IIS 7.5公共服務器上的表單驗證SaaS的ASP.NET 3.5 Web應用程序exsisting形式。我們也有運行ASP.NET MVC的一些子應用2.如何AD認證+ SSO整合與認證薩斯web應用
用戶名和密碼存儲在我們的數據庫和每個用戶都有角色和連接組，定義權限和訪問權限。
現在，我們已經要求也便於通過Active Directory簡單SSO登錄，這樣用戶不必輸入用戶名和密碼兩次登錄。這些用戶將來自不同的網絡和域。到LDAP服務
無用戶「同步」應該採取從我們的服務器。我們不確定是否需要與LDAP進行任何溝通，因爲所有用戶都將在我們的系統中創建並維護。表單身份驗證將用於大多數用戶。
從這裏開始，我們不確定這是選擇最佳路徑。對於我們的場景，什麼是「最佳實踐」方式？
簡單的答案是SAML。它被認爲是「最佳實踐」，許多大型SAAS提供商都支持它。
SAML協議定義了多個系統之間的單點登錄流。它建立使用證書的系統之間的信任。您的應用程序接受一個斷言，其中包含來自其他系統的屬性（用戶標識，名稱，電子郵件地址等）。您的應用會將用戶映射到您的用戶商店。
在.NET世界中有幾個選項。你可以找到一個實現SAML（ComponentSpace有一個）的庫，並將其掛接到ASP.NET身份驗證中。您可以使用Windows標識框架（WIF）創建自己的。這裏有一堆WIF視頻http://www.cloudidentity.com/blog/2010/06/23/ALL-WILL-BE-REVEALED-7-HOURS-RECORDINGS-FROM-THE-WIF-WORKSHOPS/。您可以嘗試IdentityServer http://thinktecture.github.io/
根據您的應用程序的安全程度，您可以選擇使用簡化方法從可信網絡傳遞用戶標識的簡單選項。我見過的應用程序允許通過URL參數或表單字段發送用戶標識。當然，這是非常不安全的，而且你承擔了更多的風險，因爲兩個網絡之間的信任沒有加密執行。您可以通過檢查引用者字符串或IP地址來緩解它（如果您可以隔離公司網絡的IP範圍）。但是你仍然開放欺騙，因爲任何用戶都可以通過在HTTP請求中替換用戶標識來模擬其他用戶。
它可能並沒有完全回答你的問題，但希望你們點在正確的方向。
我建議考慮ADFS 2.0是非常強大的聲明映射方面與AD作品：http://msdn.microsoft.com/en-us/magazine/ee335705.aspx
你會怎麼做是一個令牌消耗你的應用程序的一部分，將接收並解析返回的最終索賠在身份驗證循環之後將您的網絡服
據我所知ADFS只適用於廣告，所以它會作爲一個IdP，如果我們假設所有身份提供者都是基於AD的。對於其他LDAP，您必須尋找其他解決方案。 ADFS不會作爲依賴方，因爲有問題的應用程序使用SQL作爲用戶存儲。 WIF雖然會工作。 – Sergey 2013-04-16 01:05:59
所有你的問題的答案在這裏http://msdn.microsoft.com/en-us/library/ff423674.aspx – 2013-04-15 19:07:46