翻譯自CodeProject網站ASP.NET9月份最佳文章：Single Sign On (SSO) for cross-domain ASP.NET applications。

　　翻譯不妥之處還望大家多多指導、相互交流。

　　文章分為兩部分：架構設計和程序實現，此為第一篇即：架構設計或者叫設計藍圖（Part-I - The design blue print）。:)

　　簡介

　　周一的早晨，當你正在納悶周末咋就一眨眼過去了并對接下來漫長的一周感到無比蛋疼之時，你收到了一份Email。

　　操蛋的是它既不是微軟的offer也不是Google的offer，而是客戶發來的一個新需求。

　　他說你們現在幫我們公司做了很多的ASP.NET的網站和忽悠我們上線的各種系統，現在我想要我的客戶只要在我們擁有的任何一個網站上登錄一次，那么在我所有的網站上該用戶就都已經登錄了，同樣，隨便他從哪個網站上注銷掉，那么他也就從我們所有的網站上注銷了......

　　你受不了客戶這么羅嗦了，心想不就是要一個SSO功能嗎？使用ASP.NET的form authentication不就可以實現了？因為這樣可以在同域的不用網站下共享cookie，只需要在machineKey設置一樣的配置節就可以了。放狗一搜，果然有xxxx條結果。放狗找東西可是我們程序員的特長。

　　開工前，你又掃了一眼郵件，等等，你看到了郵件中的一行話，微微一蛋疼：我們部署了那些網站，但不是都在同一個域名下。

　　你的客戶狠狠地給你來了個下馬威，好像他早就放狗搜過，因為cookie不能跨域共享，也就不能用來實現跨域驗證了。

　　這到底是神馬一回事情！（和老外一樣扯玩淡，下面正經些）

　　ASP.NET中的驗證原理

　　這個問題可能是老生常談了，但在解決難題之前，還是先回歸基礎來看一看事物的本質到底是如何的。因此，我們重溫一下ASP.NET表單驗證的原理也并不壞。
　　下面是ASP.NET表單驗證的流程圖

　　驗證流程

　　1：你訪問一個需要用戶驗證的ASP.NET頁面

　　2：在此請求中ASP.NET運行時開始查找cookie(由于表單驗證的cookie)，如果沒有查找到，那么將跳轉到登錄頁面(登錄頁地址配置在了web.config文件中)

　　3：在登錄頁面中，你提供了相關的驗證憑證并點擊了登錄按鈕，系統和已存儲的數據對比驗證成功后，將Thread.CurrentPrincipal.Identity.Name的屬性值設置成了你提供的用戶名，并在Response中寫入了cookie(同時還寫入了用戶信息和一些如cookie名，失效日期等)，并重定向到登錄前的頁面。

　　4：當你再點擊其他的頁面(或者點擊導航到其他的頁面)，瀏覽器發送驗證的cookie(也可能包含在該網站下寫入的一些其他cookie)，這一次已經包含了在上一次response中上次驗證獲取到的cookie。

　　5：和以前一樣，ASP.NET運行時在請求中查找驗證的cookie，這一次找到了，接下來做一些檢查(如失效日期、路徑等等)，如果還沒有失效，那么讀取出它的值，恢復出用戶的信息，將Thread.CurrentPrincipal.Identity.Name的屬性值設置成恢復出的用戶名，檢查該用戶是否有權限去訪問當前請求的頁面，如果有，那么頁面執行的結果返回到用戶的瀏覽器。

　　過程很簡單，對嗎？

　　ASP.NET中多站點同域下的驗證原理

　　如前所述，ASP.NET表單驗證完全依賴于cookie。那么只要使得不同的站點共享同樣的驗證cookie，那么就可以實現在一個站點登錄實現所有站點的登錄。

　　HTTP協議指出，如果兩個站點是同域(或者是子域)的，那么可以共享cookie。本地的處理是瀏覽器根據網站的URL存儲cookie在本地(磁盤或者內存中)。當你請求接下來的任意頁面時，瀏覽器讀取和當前請求的URL匹配的域或子域的cookies，并將此cookies包含在當前的請求中。

　　現在我們假設有下面兩個網站：

　　www.mydomain.com/site1

　　www.mydomain.com/site2

　　這兩個站點共享同樣的主機地址(同樣的域mydomain.com和子域www)，且兩個站點都被配置成了對用戶驗證和授權都使用表單驗證。假設你已經登錄過了站點www.mydomain.com/site1，如前所述，你的瀏覽器現在對于站點www.mydomain.com/site1已經有了表單驗證的cookie。

　　現在你隨意訪問以www.mydomain.com/site1開頭的URL，表單驗證的cookie都將被包含在請求被發送。為什么？是因為此cookie本來就屬于該站點嗎？對的，但不是完全正確。事實上，是因為請求的URL：www.mydomain.com/site1和http://www.mydomain.com/擁有同樣的域名和子域名。

　　那么在你登錄了www.mydomain.com/site1后，如果你點擊www.mydomain.com/site2下的URL，表單驗證的cookie也將被包含在請求中發送，這同樣是因為www.mydomain.com/site2與站點http://www.mydomain.com/擁有同樣的域名和子域名，盡管它是不一樣的應用站點(site2)。顯然，在擁有一樣主機地址不一樣的應用站點名之間是可以共享表單驗證cookie的，這樣就實現了一處登錄處處都已經登錄的功能(也就是單點登錄)。

　　然而，ASP.NET沒有允許你僅僅通過將同主機地址下的站點部署上表單驗證后就自動完成了單點登錄。為什么這樣呢？因為每一個不同的ASP.NET web應用程序使用它自己的密鑰去加密和加密cookie(還有諸如ViewState之類的)從而確保了安全。除非你給每一個站點指定了同樣的加密密鑰，那么cookies將被發送，但是另一個應用站點不能夠讀取驗證cookies的值。

　　指定同樣的驗證密鑰可以解決這個問題。為每一個ASP.NET應用站點使用同樣的<machinekey>配置節即可，如下：

操作流程：

　　請求http://www.domain1.com/中一個需要驗證的頁面

NET技術：跨域SSO的實現之一：架構設計，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。