ASP.NET網站跨子網域名稱單點登陸（SSO）的實現ASP.NET網站跨子網域名稱單點登陸（SSO）的實現

 http://blog.csdn.net/jason_dct/article/details/8502075 ASP.NET網站跨子網域名稱單點登陸（SSO）的實現

在MSDN的文檔“配置跨應用程式的 Forms 身分識別驗證（http://msdn2.microsoft.com/zh-CN/library/eb0zx8fc.aspx）” 中，提出了在Web Farm和多個應用程式之間實現共用身份登陸資訊的方法。這個方法實現的其實是場環境下的身份共用，對於跨子網域名稱的單點登陸，如網易和CSDN的通行證的實現，也有很多朋友給出瞭解決方案，參見：http://www.cnblogs.com/dudu/archive/2005/07/04/186279.html

Form驗證其實是基於身份cookie的驗證。客戶登陸後，產生一個包含使用者身份資訊（包含一個ticket）的cookie，這個cookie的名字就是在web.config裡Authentication節form設定的name資訊，如

<authentication mode="Forms">
   <forms loginUrl="login.aspx" name=".ASPXAUTH" path="/" protection="All" ></forms>
 </authentication>

這裡，.ASPNETAUTH就是這個Cookie的名字。通過在Request.Cookies集合裡包含這個cookie，實現使用者身份資訊的傳遞。所以，共用身分識別驗證資訊的思路很簡單：只要這個身分識別驗證cookie能在自網域名稱中共用，Form驗證資訊自然可以共用！

共用Cookie的文章網上很多，基本的做法就是設定Cookie的domain屬性。cookie的domain指定了此cookie所關聯的域。domain預設為String.Empty，表示關聯的域是當前Request對應的域。如果domain設定一個子網域名稱，如cookie.Domain="brookes.com"，則表示此cookie關聯brookes.com下所有的下級域。因此，可以被www.brookes.com/web2.brookes.com......等共用。

至此，實現跨子網域名稱的Form驗證資訊共用的方法就很簡單：

 if (Membership.ValidateUser(userName, password))
          ...{
                FormsAuthentication.SetAuthCookie(userName.Text, false);
                HttpCookie cookie = Response.Cookies[FormsAuthentication.FormsCookieName];
                cookie.Domain = ".brookes.com";
                Response.Cookies.Add(cookie);
                FormsAuthentication.RedirectFromLoginPage(userName,false);
            }

這個代碼說明的是實現的原理。這裡，實現的自己寫Form驗證的過程。如果使用的是Login控制項，由framework自己完成驗證，怎麼設定這個cookie的domain呢？

可以有三種方式：

1. 在Login.OnLoggedIn事件中處理。這個事件在使用者通過身分識別驗證後觸發，驗證cookie已經存在，可以修改其domain屬性，代碼參考上面；
2. 將驗證使用者、設定AuthCookie的過程寫成一個HttpMoudle。這個方法稍負責，可google代碼
3.有一個最最最簡單的方法，在.net 2.0 中，Authticainon的forms元素新添了一個屬性：domain。這個屬性對應的就是form的AuthCookie的domain屬性。因此，只需要在每個子域的web.config中作如下設定：

<authentication mode="Forms">
   <forms loginUrl="login.aspx" name=".ASPXAUTH" path="/" protection="All" domain="brookes.com"></forms>
 </authentication>

OK，現在你不需要作任何其他設定了，你的brookes.com下所有的子域都可以共用form驗證身份資訊了！

還要說明幾點：
1. 這個domain屬性會覆蓋在httpCookie配置節的domain屬性設定，但是只會影響到AuthCookie，其他cookie不受影響；
2. 看了上面這一條，當然會想到我可以設定httpCookies配置節，如：
   <httpCookies domain="brookes.com"/>
  效果是一樣的。不同指出在於，httpCookies指定了網站內所有cookie的domain屬性，這將導致網站內所有的cookie都可以在子域間共用！至於這種共用是需要還是該避免，根據需要具體判斷。
3. 這個domain屬性，我看到在有的文檔裡強調在前面加一個點，如domain=".brookes.com"，而MS的文檔裡都沒有這個點。根據我的測試結果，兩個寫法沒有區別，效果一樣。

 

-----------------------------------------------------------------------------------------------------------------------------------------

1 對於純web得sso,如果有獨立得SSO登陸伺服器，所有的驗證都跳轉到這個伺服器的介面，登陸的狀態保留在sso server上

2 如果要案頭和web共同認證，還是必須有獨立得SSO，

對於自己實現的方案，例如如果是通過一個傳統型程式來實現SSO，那麼必須有一台SSO伺服器，傳統型程式通過httpclient驗證身份，然後可以通過
a. 修改本機cookies讓IE傳認證令牌
b. 直接把認證令牌作為url字串根在傳統型程式的一個連結後面

令牌說法比較含糊,具體兩種方法：
1 所有得url均複寫令牌
2 只要保留瀏覽器對SSO web server的cookies,跳轉應用程式的時候，web app先redirect到ssoserver，驗證cookies後，跳回來，對使用者來說，感覺不到去過ssoserver，呵呵，

很多網站，例如google好像就是這個方法

jaas本質上只解決一個登入可配置的問題，像tomcat用jaas，只能解決同時登陸tomcat上得N個應用，而且僅限於java，對SSO實現還是要按上面的方法。kerberos往往是和系統一

些模組緊密結合的，擴充不一定方便。

3 如果windows是唯一登入入口，也就是沒有第二台SSO登入伺服器。
那麼實現SSO的核心，就是登入網域之後，IE能夠把域資訊發送給服務端：

  配置IE瀏覽器
  ①internet選項-->安全-->本地intranet-->網站-->進階
  添加wls
  ②internet選項-->進階-->安全
  確定,整合windows身份認證被選中

服務段的weblogic接收到這個令牌以後，要去AD上驗證

整合Windows身分識別驗證(以前稱為NTLM身分識別驗證和Windows NT質詢／響應身分識別驗證)可以使用NTLM或Kerbetas身分識別驗證，NTLM是Microsoft的一項專有技術，自問世以來已幾經更新，

雖然這種機制穩定可靠但它有一個致命缺點是不能進行委派，這就意味著使用者憑證不能流動到遠程服務(如SQL Server)。而Kerberos卻不存在這種問題，在保持穩定安全的驗證機

制的同時還可以在Windows環境中輕鬆地使用委派，我們要討論的就是這種機制。

Kerberos大多數情況下要求使用Microsoft Active Directory，因為Active Directory 充當Kerberos令牌授予服務(TGS／TGT)。

如果用kerberos，那就很簡單了，windows和weblogic都支援kerberos，認證資料都在AD上
參考資料  http://edocs.bea.com.cn/wls/docs92/secmanage/sso.html

 

from:http://www.cnblogs.com/csdnexpert/archive/2007/12/17/999415.html

 

 

-------------------------------------------------------------------------------------------------------------------------------------------

Java SSO參考：http://www.cnblogs.com/hannover/archive/2009/10/15/1583692.html

在MSDN的文檔“配置跨應用程式的 Forms 身分識別驗證（http://msdn2.microsoft.com/zh-CN/library/eb0zx8fc.aspx）” 中，提出了在Web Farm和多個應用程式之間實現共用身份登陸資訊的方法。這個方法實現的其實是場環境下的身份共用，對於跨子網域名稱的單點登陸，如網易和CSDN的通行證的實現，也有很多朋友給出瞭解決方案，參見：http://www.cnblogs.com/dudu/archive/2005/07/04/186279.html

Form驗證其實是基於身份cookie的驗證。客戶登陸後，產生一個包含使用者身份資訊（包含一個ticket）的cookie，這個cookie的名字就是在web.config裡Authentication節form設定的name資訊，如

<authentication mode="Forms">
   <forms loginUrl="login.aspx" name=".ASPXAUTH" path="/" protection="All" ></forms>
 </authentication>

這裡，.ASPNETAUTH就是這個Cookie的名字。通過在Request.Cookies集合裡包含這個cookie，實現使用者身份資訊的傳遞。所以，共用身分識別驗證資訊的思路很簡單：只要這個身分識別驗證cookie能在自網域名稱中共用，Form驗證資訊自然可以共用！

共用Cookie的文章網上很多，基本的做法就是設定Cookie的domain屬性。cookie的domain指定了此cookie所關聯的域。domain預設為String.Empty，表示關聯的域是當前Request對應的域。如果domain設定一個子網域名稱，如cookie.Domain="brookes.com"，則表示此cookie關聯brookes.com下所有的下級域。因此，可以被www.brookes.com/web2.brookes.com......等共用。

至此，實現跨子網域名稱的Form驗證資訊共用的方法就很簡單：

 if (Membership.ValidateUser(userName, password))
          ...{
                FormsAuthentication.SetAuthCookie(userName.Text, false);
                HttpCookie cookie = Response.Cookies[FormsAuthentication.FormsCookieName];
                cookie.Domain = ".brookes.com";
                Response.Cookies.Add(cookie);
                FormsAuthentication.RedirectFromLoginPage(userName,false);
            }

這個代碼說明的是實現的原理。這裡，實現的自己寫Form驗證的過程。如果使用的是Login控制項，由framework自己完成驗證，怎麼設定這個cookie的domain呢？

可以有三種方式：

1. 在Login.OnLoggedIn事件中處理。這個事件在使用者通過身分識別驗證後觸發，驗證cookie已經存在，可以修改其domain屬性，代碼參考上面；
2. 將驗證使用者、設定AuthCookie的過程寫成一個HttpMoudle。這個方法稍負責，可google代碼
3.有一個最最最簡單的方法，在.net 2.0 中，Authticainon的forms元素新添了一個屬性：domain。這個屬性對應的就是form的AuthCookie的domain屬性。因此，只需要在每個子域的web.config中作如下設定：

<authentication mode="Forms">
   <forms loginUrl="login.aspx" name=".ASPXAUTH" path="/" protection="All" domain="brookes.com"></forms>
 </authentication>

OK，現在你不需要作任何其他設定了，你的brookes.com下所有的子域都可以共用form驗證身份資訊了！

還要說明幾點：
1. 這個domain屬性會覆蓋在httpCookie配置節的domain屬性設定，但是只會影響到AuthCookie，其他cookie不受影響；
2. 看了上面這一條，當然會想到我可以設定httpCookies配置節，如：
   <httpCookies domain="brookes.com"/>
  效果是一樣的。不同指出在於，httpCookies指定了網站內所有cookie的domain屬性，這將導致網站內所有的cookie都可以在子域間共用！至於這種共用是需要還是該避免，根據需要具體判斷。
3. 這個domain屬性，我看到在有的文檔裡強調在前面加一個點，如domain=".brookes.com"，而MS的文檔裡都沒有這個點。根據我的測試結果，兩個寫法沒有區別，效果一樣。

 

-----------------------------------------------------------------------------------------------------------------------------------------

1 對於純web得sso,如果有獨立得SSO登陸伺服器，所有的驗證都跳轉到這個伺服器的介面，登陸的狀態保留在sso server上

2 如果要案頭和web共同認證，還是必須有獨立得SSO，

對於自己實現的方案，例如如果是通過一個傳統型程式來實現SSO，那麼必須有一台SSO伺服器，傳統型程式通過httpclient驗證身份，然後可以通過
a. 修改本機cookies讓IE傳認證令牌
b. 直接把認證令牌作為url字串根在傳統型程式的一個連結後面

令牌說法比較含糊,具體兩種方法：
1 所有得url均複寫令牌
2 只要保留瀏覽器對SSO web server的cookies,跳轉應用程式的時候，web app先redirect到ssoserver，驗證cookies後，跳回來，對使用者來說，感覺不到去過ssoserver，呵呵，

很多網站，例如google好像就是這個方法

jaas本質上只解決一個登入可配置的問題，像tomcat用jaas，只能解決同時登陸tomcat上得N個應用，而且僅限於java，對SSO實現還是要按上面的方法。kerberos往往是和系統一

些模組緊密結合的，擴充不一定方便。

3 如果windows是唯一登入入口，也就是沒有第二台SSO登入伺服器。
那麼實現SSO的核心，就是登入網域之後，IE能夠把域資訊發送給服務端：

  配置IE瀏覽器
  ①internet選項-->安全-->本地intranet-->網站-->進階
  添加wls
  ②internet選項-->進階-->安全
  確定,整合windows身份認證被選中

服務段的weblogic接收到這個令牌以後，要去AD上驗證

整合Windows身分識別驗證(以前稱為NTLM身分識別驗證和Windows NT質詢／響應身分識別驗證)可以使用NTLM或Kerbetas身分識別驗證，NTLM是Microsoft的一項專有技術，自問世以來已幾經更新，

雖然這種機制穩定可靠但它有一個致命缺點是不能進行委派，這就意味著使用者憑證不能流動到遠程服務(如SQL Server)。而Kerberos卻不存在這種問題，在保持穩定安全的驗證機

制的同時還可以在Windows環境中輕鬆地使用委派，我們要討論的就是這種機制。

Kerberos大多數情況下要求使用Microsoft Active Directory，因為Active Directory 充當Kerberos令牌授予服務(TGS／TGT)。

如果用kerberos，那就很簡單了，windows和weblogic都支援kerberos，認證資料都在AD上
參考資料  http://edocs.bea.com.cn/wls/docs92/secmanage/sso.html

 

from:http://www.cnblogs.com/csdnexpert/archive/2007/12/17/999415.html

 

 

-------------------------------------------------------------------------------------------------------------------------------------------

Java SSO參考：http://www.cnblogs.com/hannover/archive/2009/10/15/1583692.html