我正在研究在一系列網站上實施單點登錄的選項（我的意思是單一用戶憑據對單一共享身份商店進行身份驗證的一組身份驗證） 。跨多個網站（不同域名）的SSO選項
所有網站的名義上屬於同一組織（所以我們可以假設它們之間的信任關係），但在不同的域託管，並跨越不同的技術 - INC。 .NET，Java和PHP。
我們正在整合所有用戶配置文件到一個單一的後端的CRM系統，並且需要一些方法來提供強大的訪問此所有當前（和未來）的網絡性能。
我們有一個新生的SAML提供商運行，默認選項是在所有的（目前）不支持的屬性訪問擴展到這一點。這是最好的選擇嗎？所有對SSO產品（CAS，CoSign等）的在線引用似乎都很古老（2004+）。
使用SAML協議使得這裏一噸的感覺。如果您的公司決定朝這個方向發展，它甚至可以讓您聯合基於雲的服務。
SAML確實不所需要的目標服務器（又名「服務提供者」或在MS用語「依賴方」），以使用完全限定域名與共同的DNS根被引用。它也是技術不可知的，因此服務提供商運行的HTTP堆棧確實無關緊要。
我不知道哪些接口可用到後端的CRM系統，但LDAP或SQL連接通常用於獲取身份索賠信息，並建立了SAML響應。
你可能要研究一些身份提供的產品包括微軟ADFS，PortalGuard（我爲誰工作）和中國平安。
看一看微軟的ADFS 2.0支持.NET
有跡象表明，這樣做例如商業產品PingIdentity和開放源代碼例如OpenAM。
這些產品都支持SAML。
對於Java，請在其前面放置OpenAM之類的東西或使用OpenSSO/OpenAM fedlet。
對於PHP，使用simpleSAMLphp。
用於獲取當前引用的關鍵字是「SAML聯合」。
謝謝格雷格 - 我們認爲延長SAML部署是有道理的，但有這麼小了最新的SSO，似乎它可能在無處不在的社會登錄機制的臉已經搶救無效而死亡在網絡上。很高興知道它還活着。 –