跨域SSO的实现
?
翻譯自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>配置節即可，如下：
<machineKey???validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D"?
??decryptionKey="ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F"
??validation="SHA1"
??decryption="AES"/>
如果同樣的machinekey(包括validationKey和decryptionKey)被用在同域下的所有應用站點時，就可以實現了跨站點讀取cookie。
如果是同樣的域不同的子域呢？
假定你有下面兩個站點：
site1.mydomain.com
site2.mydomain.com
這兩個站點共享同樣的域(同樣的二級域名mydomain.com)，但擁有不一樣的三級域名(不一樣的子域site1和site2)。
默認情況下瀏覽器僅僅發送主機地址一樣(相同的域和子域)的站點的cookie。因此站點site1.mydomain.com不能獲取到站點site2.mydomain.com下的cookie(因為他們沒有相同的主機地址，它們的子域不同)，盡管你為這兩個站點配置了相同的machineKey，一個站點還是不能獲取另一個站點下的cookie。
除了你為所有的站點配置了一樣的machineKey，你還需要為驗證cookie定義相同的域以使得瀏覽器在同樣的域名下能夠發送任何請求。
你需要像下面這樣配置表單驗證cookie：
<forms?name="name"?loginUrl="URL"?defaultUrl="URL"?domain="mydomain.com"/>那么，在不用的域下如何去共享驗證cookie呢?
顯然這是不可能的，因為HTTP協議基于安全的原因阻止了你在不同的域之間共享cookie。
同樣，假設有下面這兩個域名：
http://www.domain1.com/
http://www.domain2.com/
如果你使用表單驗證登錄進了http://www.domain1.com/，當你點擊http://www.domain2.com/下的URL時，瀏覽器將不能發送domain1.com的cookie到domain2.com。在ASP.NET中沒有內置的方法去完成在兩個不同的站點間實現單點登錄。
要在兩個站點間通過訪問同樣的cookie來實現單點登錄，還真沒有什么高級的技巧或即有的架構模型去解決它。
跨域單點登錄設計雛形
假設有下面三個站點：
http://www.domain1.com/
http://www.domain2.com/
http://www.domain3.com/
為了實現在這些站之間實現SSO，當用戶在任意一個站登錄時，我們需要為所有的站點設置驗證cookie。
如果用戶1登錄進http://www.domain1.com/，那么在給站點1response前會在response中加入驗證的cookie，但當我們需要同時能夠登錄進http://www.domain2.com/和http://www.domain3.com/時，我們需要同時在同樣的客戶端瀏覽器上為站點2和站點3設置驗證cookie。因此，在response返回到瀏覽器前，站點1不得不定向到站點2和站點3去設置驗證cookie。
下面的流程圖詳細描述了思路：
操作流程：
http://www.domain1.com/驗證用戶提供的登錄憑證，驗證通過后，標記用戶的狀態為已登錄，添加驗證的cookie和其他的用戶信息一起添加在response中 狀態：瀏覽器沒有驗證cookie response并沒有返回給瀏覽器，而是將請求重定向到http://www.domain2.com/的一個頁面，并將ReturnUrl設置成重定向前http://www.domain1.com/的URL值。在驗證cookie被包含在了response中了后，cookie被發送給瀏覽器。 狀態：瀏覽器沒有驗證cookie 瀏覽器接收到了包含驗證cookie的response和重定向到http://www.domain2.com/的命令。瀏覽器存儲了http://www.domain2.com/的驗證cookie并向http://www.domain2.com/發送請求。 狀態：瀏覽器包含了http://www.domain2.com/的驗證cookie http://www.domain2.com/立即再重定向到存儲在ReturnUrl中的URL地址，在此請求中讀取cookie值并為http://www.domain1.com/設置驗證cookie。最終，在重定向的命令中也包含了這些驗證cookie。 狀態：瀏覽器包含了http://www.domain2.com/的驗證cookie 瀏覽器接收到包含了驗證cookie的重定向命令跳轉到http://www.domain1.com/。現在瀏覽器存儲了站點1的驗證cookie并開始請求站點1，當然在請求中包含了驗證cookie。 狀態：瀏覽器包含了http://www.domain1.com/和http://www.domain2.com/的驗證cookie 站點1檢查了請求中包含了驗證cookie，就不需要再去跳轉到驗證頁面去驗證，而是返回用戶請求的頁面 狀態：瀏覽器包含了http://www.domain1.com/和http://www.domain2.com/的驗證cookie
如果此時用戶請求站點2， 因為瀏覽器已經存儲了站點2的驗證cookie，cookie將被包含在請求中，站點2從cookie中獲取到用戶信息，并為此用戶返回請求的頁面。
當瀏覽器驗證了站點2和站點3后，那么用戶就已經登錄了所有的站點，這樣就完成了一次單點登錄。
如何單點注銷？
作為單點登錄的一部分，我們還需要去關注下單點注銷，就是說當用戶在一個站點注銷后，那么就認為他從所有的站點都注銷了。
清除所有站點的cookie和上面登錄一樣，也是請求-重定向-返回的過程。只是和設置驗證cookie不一樣的是，這次從response中移除驗證cookie。
此單點登錄模型的缺點
這個模型在兩個站點上還是能運行的很好的。從一個站點登錄或注銷，此SSO模型下的站點都將遵從請求-重定向-返回的流程。當用戶登錄任一頁面時，因為已經存儲了所有站點的驗證cookie，那么就不需要再執行上面的那個循環的流程了。
但是當站點超過兩個時，問題就變得復雜了，當登錄站點1時，程序將重定向到站點2和站點3進行驗證cookie的設置，最后站點3在跳轉到站點1，服務器返回用戶請求的頁面。這使得每個站點的登錄和注銷的過程變得復雜并花費較高的代價。如何超過3個站點呢？如果這樣去設計20+站點的單點登錄呢？這個模型將完全不能勝任了。
并且此模型需要每個站點都具備用戶驗證邏輯，因為需要來請求此站點并設置其驗證cookie。
因此此模型丟失了一般意義上的單點登錄的概念，我們需要一個更好一點的模型去實現單點登錄的功能。
更好的跨域單點登錄架構
前面提到的架構中，設置移除cookie都需要跳轉到N-1個站點去完成。每個站點還需要知道N-1個站點復雜的登錄注銷邏輯，
如果我們為所有的站點只去維護一份驗證cookie呢？使用一個獨立的站點去完成驗證用戶并設置驗證cookie的工作呢？這個想法好像不錯。
要使用單點登錄，那么就需要用戶的數據是統一的，這樣的話就可以通過一個站點提供web或者WCF服務來完成驗證和授權的功能。這樣就省去了冗余的用戶驗證邏輯，現在最重要的是這個獨立的站點如何在SSO架構中起作用。
在這個架構模型中，瀏覽器不存儲任何其他站點的驗證cookie，只存那個獨立站點的驗證cookie，我們就給它起名叫http://www.sso.com/。
在此架構中，對每一個站點的請求都將被直接跳轉到http://www.sso.com/，由于檢查驗證cookie是否存在。如果cookie存在，如果存在，返回請求的頁面，如果不存在，那么就跳轉到對應的登錄頁面。
大致流程圖如下：
便于理解，我們假定有下面兩個網站：
http://www.domain1.com/
http://www.domain2.com/
還有一個用于管理驗證cookie的站點：http://www.sso.com/。
驗證流程如下：
用戶請求http://www.domain1.com/中一個需要驗證的頁面
重定向到http://www.sso.com/，ReturnUrl參數設置成請求站點1時的URL。
http://www.sso.com/檢查是否有驗證cookie存在，如果在請求中沒有任何用戶令牌存在，那么請求中帶著用戶需要登錄的指令就跳轉到站點1。在query string中仍然保留著之前ReturnUrl參數的值。
站點1從參數中得知是從http://www.sso.com/跳轉而來，且得知沒有用戶驗證cookie，最后跳轉到站點1的登錄頁面進行登錄，而不跳轉到http://www.sso.com/。
用戶提供驗證信息點擊登錄按鈕，請求沒有回置到站點http://www.sso.com/，這時，站點1通過http://www.sso.com/提供的web/WCF接口進行用戶的驗證，如果驗證成功，那么為用戶頒發一個令牌(可以是一個GUID)。
站點1標志用戶已經登錄成功（在session中存儲用戶對象），一個包含了令牌的URL跳轉到http://www.sso.com/設置驗證cookie，ReturnUrl參數還是設置成前面請求的URL。
http://www.sso.com/站點檢查過來的URL，發現有用戶令牌，但還沒有用戶驗證cookie，說明已經通過了站點1的認證，現在需要設置站點http://www.sso.com/下的驗證cookie。照例設置好了cookie后，將cookie添加在response中，還添加上用戶令牌按照ReturnUrl參數中的URL一并返回。
瀏覽器得知要跳轉到站點1，并且有了站點http://www.sso.com/的驗證cookie，在本地存儲下sso站點的驗證cookie并對站點1發起請求。
站點1檢查了用戶令牌，因為是通過站點SSO的web/WCF服務驗證并通過的，所以站點1返回用戶請求的頁面。
現在用戶請求站點2
瀏覽器跳轉到sso站點，依然設置好ReturnUrl的值。
瀏覽器因為要跳轉到sso站點，發現本地有了sso站點的驗證cookie，所以將cookie添加在請求中一并發出。
sso站點檢查cookie，發現cookie還沒有過期，那么在query string中添加上用戶令牌按照ReturnUrl返回。
站點2發現有用戶令牌，證明已經走過驗證流程，那么就返回用戶請求的頁面。
總結
剛開始，瀏覽器沒有任何http://www.sso.com/站點下的驗證cookie。請求站點1和站點2任何需要驗證的頁面(需要內部的跳轉到sso站點檢查驗證cookie是否存在)。用戶登錄后，sso站點的驗證cookie存儲在本地（重要的是用戶令牌僅僅用戶用戶登錄會話時）。
現在請求站點1或者站點2都跳轉到sso站點，瀏覽器發送sso站點的驗證cookie并檢查用戶令牌，驗證后再跳轉到原始請求的URL，原始站點檢查用戶令牌正確后返回用戶請求的頁面。
傳輸代價
場景1：訪問公共頁面
從瀏覽器到站點+站點到瀏覽器
1請求+1返回
場景2：訪問一個需要驗證的頁
從瀏覽器到站點+重定向到sso站點（檢查cookie）+重定向到原站點（沒有cookie）+原站點返回登錄頁面到瀏覽器
1請求+2跳轉+1返回
場景3：登錄
瀏覽器POST到站點+調用驗證服務進行用戶驗證+瀏覽器跳轉到SSO站點（帶有令牌）+重定向到原站點（帶有驗證cookie）+通用服務驗證令牌+返回用戶請求的需要驗證的頁面
1請求+2驗證服務調用+2跳轉+1返回
場景4：登錄后請求一個需要驗證的頁面
請求站點+向SSO站點跳轉驗證cookie（帶有驗證cookie）+跳轉到原站點（檢查驗證cookie）+調用服務驗證令牌+返回請求頁面
1請求+2跳轉+1服務請求+1返回
場景5:注銷
請求站點進行注銷+請求SSO站點進行注銷+請求原站點移除驗證cookie+返回
1請求+2跳轉+1返回
孰是孰非
比較這兩種架構，第一中架構更適合兩個站點，最多三個站點，雖然需要部署復雜冗余的驗證邏輯，但是隨后的頁面請求中就是普通的頁面請求了（1請求+1返回）。
第一種架構不易于擴展，且會冗余出很多的用戶驗證邏輯。
而第二種架構，不管有多少個需要進行單點登錄的網站，也不需要其他網站參與此過程，驗證的cookie只有sso站點管理，這樣的架構邏輯清晰、易擴且部署方便。
然而有一些性能的問題，不同于第一種架構，這種架構當用戶請求一個需要驗證的頁面時需要請求三次（請求sso站點和原站點，兩次請求是內部的跳轉），且多的兩次請求花費的時間很少（空跳轉請求，用于設置和檢查cookie），在如今這樣的網絡環境下是可以接受的。
轉載于:https://www.cnblogs.com/B-bowen/p/3939891.html
總結
- 上一篇： IOS sqlite数据库增删改查
- 下一篇： Solr4.7新建core