系統(tǒng)的基本架構
　 　我們假設一個系統(tǒng)System包含Service客戶服務中心、Shop網上購物中心和Office網上辦公中心三個獨立的網站。 Service管理客戶的資料，登錄和注銷過程。不論客戶訪問System的任何一個頁面，系統(tǒng)都會轉到登錄界面，在用戶登錄后，系統(tǒng)會自動轉會到客戶上 次請求的頁面。并且用戶此后可以在System中無縫切換。不需要再次進行登錄。即在System中實現(xiàn)單點登錄SSO（Single Sign-On）。
　　我們知道，用戶的即時狀態(tài)通常是使用Application、Session、Cookie和存儲的。而這些都是不能在程序中跨站點訪問的。我們必需通過站點間相互通訊來確認用戶的即時狀態(tài)。
　簡單的實現(xiàn)
　 　第一步，假設用戶訪問了Shop或Office的任何一個頁面Any。該頁面所在的網站將會檢查用戶的即時狀態(tài)。如果用戶已經登錄了，則將 Any頁面的信息返回給用戶。如果用戶還沒有登錄，則自動轉到Service的Validate頁面，驗證用戶在Service狀態(tài)。即Shop或 Office向Service發(fā)出請求，要求Service返回用戶的即時狀態(tài)。
　　第二步，Validate驗證用戶的即時狀態(tài)，如果 用戶已經登錄了，則Service將用戶的即時狀態(tài)返回給Shop或Office的同步頁面 Synchronous，通知Shop或Office同步用戶狀態(tài)。如果用戶沒有登錄，則自動轉向Customer頁面，提示用戶登錄。
　　第三步，用戶完成登錄過程，當用戶成功登錄后，自動轉回Validate頁面，通知Shop或Office的Synchronous進行用戶狀態(tài)的同步。
　　第四步，在用戶狀態(tài)同步完成后，在本地站點，用戶狀態(tài)成為在線狀態(tài)，即可訪問Any頁面。
　　在上面的流程中。我們知道，不管用戶訪問哪個站點，用戶只需要一次登錄，就保證用戶在Service的即時狀態(tài)都是在線的，不會再需要進行第二次登錄的過程。
　　現(xiàn)在我們的思路已經清楚，具體的實現(xiàn)我們將在代碼分析中完成。
代碼分析
　　從上面的流程中我們可以看出，系統(tǒng)中Shop和Office的代碼是完全類似的。只要Shop可以實現(xiàn)，Office也可以同樣的克隆。所以我們的重點分析的對象是Shop和Service的代碼。
　　1、Shop的Web.config和Project.cs
　　在Shop的Web.config里，我們配置了Service站點和Shop站點，以方便我們在部署時方便修改。

　在Project類里進行引用。

　　2、Shop的Global.cs
　 　Shop的Global.cs定義了四個Session變量，UserID用來標識用 戶身份。Pass標識用戶即時狀態(tài)，Security用于保存往來Service和Shop的通訊不是被仿冒的。Url保存了上次請求的頁面，以保證在用 戶登錄后能轉到用戶請求的頁面。

　　3、Shop的Any.cs
　　Shop的Any.cs并沒有包含代碼，因為Any類從Page繼承而來，為了代碼分析方便，我們將代碼集中到Page.cs中。

　　4、Shop的Page.cs
　　Page類有兩個方法，CustomerValidate和Initialize。CustomerValidate用戶檢查用戶的即時狀態(tài)，而Initialize是頁面登錄后發(fā)送給用戶的信息。我們的重點是CustomerValidate。
　 　CustomerValidate是一個非常簡單的流程，用條件語句檢查Pass的狀態(tài)，如果Pass為否，則表示用戶沒有登錄，頁面跳轉到 Service的Validate頁面中。我們要分析的是其中保存的Url和遞交的WebSite和Security幾個參數(shù)。Url的作用在前面已經講 清楚了，只是為了保證用戶登錄后能回到原來的頁面。而WebSite是為了保證該站點是被Service所接受的，并且保證Service知道是哪個站點 請求了用戶即時狀態(tài)。因為這個例子是個簡單的例子，在后面的Validate里沒有驗證WebSite是否是接受的請求站點，但是在實際應用中應該驗證這 一點，因為Shop和Service等同于服務器和客戶端，服務器出于安全考慮必須要檢查客戶端是否是被允許的。Security是非常重要的一點。 Shop對Service發(fā)送的是請求，不需要保證該請求沒有被篡改，但是在Service應答Shop請求時就必須要保證應答的數(shù)據(jù)沒有被篡改了。 Security正是為了保證數(shù)據(jù)安全而設計的。
　　在代碼中，Security是通過Hash一個隨機產生的數(shù)字生成的。具有不確定 性。和保密性。我們可以看到，Security同時保存在Session中和發(fā)送給Service。我們把這個Security當作明文。在后面我們可以 看到，Security在Service經過再一次Hash后作為密文發(fā)送回Shop。如果我們將Session保存的Security經過同樣的 Hash方法處理后等到的字符串如果和Service返回的密文相同，我們就能夠在一定程度上保證Service應答的數(shù)據(jù)是沒有經過修改的。

5、Service的Global.cs
　 　現(xiàn)在我們頁面轉到了Service的Validate頁面，我們轉過來看 Service的代碼。在Global中我們同樣定義了四個Session變量，都和Shop的Session用處類似。WebSite是保存請求用戶即 時狀態(tài)的站點信息。以便能在登錄后返回正確的請求站點。

　　6、Service的Validate.cs
　　首先，將Shop傳遞過來的參數(shù)保存到Session中。如果用戶沒有登錄，則轉到Customer頁面進行登錄。如果用戶已經登錄了。則將用戶即時狀態(tài)傳回給Shop站點。如上所述，這里將Security重新Hash了一次傳回給Shop，以保證數(shù)據(jù)不被纂改。

　　7、Service的Customer.cs和Login.cs
　 　Customer主要的是一個用于登錄的表單，這里就不 貼出代碼了。這里分析一下Login的一段代碼，這段代碼是當?shù)卿浭侵苯釉赟ervice完成的（WebSite為空值），則頁面不會轉到Shop或 Office站點。所以應該暫停在Service站點。系統(tǒng)如果比較完美，這里應該顯示一組字系統(tǒng)的轉向鏈接。下面我們看到，當Pass為真時，頁面轉回 到Validate頁面，通過上面的分析，我們知道，頁面會轉向Shop的Synchronous頁面，進行用戶狀態(tài)的同步。

　　8、Shop的Synchronous.cs
　 　好了，我們在Service中完成了登錄，并把用戶狀態(tài)傳遞回Shop站 點。我們接著看用戶狀態(tài)是怎么同步的。首先，如果Session里的Security是空字符串，則表示Shop站點沒有向Service發(fā)送過請求，而 Service向Shop發(fā)回了請求，這顯然是錯誤的。這次訪問是由客戶端偽造進行的訪問，于是訪問被拒絕了。同樣Security和 InSecurity不相同，則表示請求和應答是不匹配的?？赡軕鸨蛔敫倪^了，所以應答同樣被拒絕了。當檢驗Security通過后，我們保證 Serive完成了應答，并且返回了確切的參數(shù)，下面就是讀出參數(shù)同步Shop站點和Service站點的用戶即時狀態(tài)。

　9、Shop的Page.cs
　 　我們知道，頁面在一段時間不刷新后，Session會超時失效，在我們一直訪問Shop的 時候怎么才能保證Service的Session不會失效呢？很簡單，我們返回來看Shop的Page.cs。通過在所有Shop的頁面內都用 ＜iframe＞嵌套Service的某個頁面，就能保證Service能和Shop的頁面同時刷新。需要注意的一點是Service的Session必 須保證不小于所有Shop和Office的Session超時時間。這個在Web.config里可以進行配置。

總結
　 　一次完整的登錄完成了。我們接著假設一下現(xiàn)在要跳到Office的Any頁面，系統(tǒng)會進行怎樣的操作 呢？Any（用戶沒有登錄）-＞Validate（用戶已經登錄）-＞Synchronous（同步）-＞Any。也就是說這次，用戶沒有進行登錄的過 程。我們通過一次登錄，使得Service的用戶狀態(tài)為登錄，并且不管有多少個網站應用，只要這些網站都保證符合Shop的特性，這些網站就都能保持 Service的用戶狀態(tài)，同時能通過Service獲得用戶的狀態(tài)。也就是說我們實現(xiàn)了SSO

最新評論