JSP .NET PHP SSO

Question

我有以下情況：Website1-php Website2-ASP.Net Website3-jsp我需要實現單點登錄，因為這些網站相互依賴。 有沒有一種方法可以創建一個可以在身份驗證請求中獲取的cookie？ 那么，當用戶在其中一個網站上登錄時，我們存儲的cookie可以被其他兩個網站讀取和解密，以便在重定向后處於登錄狀態？ 我正在使用相同的數據庫和相同的表“ shared.Users”來存儲用戶憑據。 這里有什么幫助嗎？ 謝謝

Answer 1

簡短的回答：是的。

更長的答案：

a）如果服務器位於相同的域（可以是不同的子域，但必須是相同的根域），則它們都可以讀取相同的cookie。 登錄服務器創建一個具有會話ID的cookie，第二個網站的訪問者讀取該cookie並傳遞給服務器，服務器對登錄服務器進行后端調用以獲取會話/用戶詳細信息並在用戶上簽名。

b）如果服務器位於不同的域，則有兩個選擇。 一種是將會話ID作為字符串傳遞給第二台服務器（丑陋）。 但是更好（也更復雜）的是一系列隱藏幀。 （您需要在IE中使用P3P才能正常工作-其他瀏覽器都可以）。 基本上，隱藏的框架是從登錄域加載的，並且可以對其進行讀取/操作以獲取會話ID。 這有點雜耍，但是當您將其繪制出來時效果很好。

---

編輯：單一登錄選項（詳細信息）

您有兩個服務器，分別稱為“ A”和“ B”。

“ A”保存身份驗證/登錄系統，“ B”是您登錄“ A”時要登錄的服務器。

如果兩台服務器提供完全獨立的頁面，或者其中一台是另一台中的iFrame，則此方法將起作用。 也可以在不同平台上使用

首先要注意的是：服務器“ A”需要與服務器“ B”共享信息。 有兩種方法，具體取決於您的情況。 第一個選擇是它們都共享同一個數據庫並在其中存儲數據，另一個選擇是服務器彼此“交談”：如果使用后者，請使用CURL並添加校驗和並向HTTP調用添加特定的頭-這應該使其足夠安全（只要沒有人看到代碼）。 如果兩者不在同一數據中心中，則還應該在兩者之間添加SSL通信-但用戶將永遠不會看到這些呼叫。 我以為您不會共享數據庫（不同的平台），因此您需要允許服務器一起交談。

服務器“ A”上會發生什么

“ A”提供一個頁面並提供一個會話“ X”，並將“ Y”存儲在cookie中。

無論用戶使用什么服務器，都應將用戶發送到“ A”進行登錄。 這可以通過在“張貼”到“ A”的每個頁面上都有一個登錄表單，執行彈出窗口來彈出“ A”傳遞的登錄表單或重定向到“ A”傳遞的頁面來完成。 （最后兩個是Facebook的工作方式。）

“ A”在關聯會話“ X”中的用戶與登錄的用戶上簽名。

當用戶訪問服務器“ A”給定的頁面時，一切都非常好，因為它可以讀取cookie“ X”並知道發生了什么。 因此，問題是服務器“ B”（或“ C”或“ D”等-可以擴展）。

服務器“ B”上會發生什么

當用戶從服務器“ B”訪問頁面時，您無法從“ A”讀取cookie。 因此，有一個簡單的選擇和一個復雜的選擇

簡單：從服務器“ A”創建的頁面到服務器“ B”的每個鏈接都將添加SessionID作為參數。 然后，服務器“ B”與服務器“ A”對話以獲取會話詳細信息。 如果用戶始終從服務器“ A”轉到服務器“ B”，而不是直接到達服務器“ B”（例如通過Google等），則該功能很好。 實際上，這不是一個好選擇。

復雜：這是事件的順序。

• B向用戶分配會話“ Y”，並將其存儲在cookie中。

• B提供了一個包含“隱藏” iFrame的網頁。 隱藏的iFrame的src將是“ A”傳遞的頁面，並且您將會話“ Y”作為GET參數附加到調用中。

• iFrame可以訪問會話“ X”（通過cookie）和會話“ Y”（通過GET參數）。

• （慢慢閱讀：）iFrame告訴服務器“ A”，如果您從服務器“ B”聽到用戶擁有會話“ Y”，則向會話“ B”提供與會話“ X”相同的憑據-即會話“ Y”與“ X”相同，將兩者鏈接在一起。

• （現在棘手的部分）一旦建立了鏈接，服務器“ B”就需要聯系服務器“ A”並說“我正在會話” Y，是這個人嗎？

已登錄？'。 服務器“ A”會將“ X”匹配為“ Y”，並說“是的，這是用戶的詳細信息”。

當然，這不是那么簡單...：

這種方法的問題是“ B”傳遞的第一頁將假定用戶尚未登錄。 （在iFrame與之通信之前，服務器“ A”將不會鏈接“ X”和“ Y”，因此，當服務器“ B”詢問服務器“ A”您是否知道“ Y”時，答案將為“否”。 ）因此，您需要監視服務器“ A”，讓服務器“ B”知道其已登錄。 您可以通過幾種方式執行此操作：

• 如果服務器“ B”從未交付過帶有cookie的頁面（即會話“ Y”是新的），或者服務器“ B”查詢服務器“ A”，而服務器“ A”則響應它從未聽說過會話“ Y”，然后使用隱藏的iFrame交付空白的“重定向頁面”，短時間后，請重試，服務器“ A”應該知道“ Y”是誰，並可以確認他是否已登錄。 或者，您提供整個頁面（未登錄），並讓JavaScript不斷調用服務器“ B”，以查看服務器“ A”現在是否知道“ Y”是誰，並且當您重新登錄時是否應該刷新用戶身份？得到回應。 [注1]

  • 您可以重復此“服務器“ B”聯系服務器“ A””的技巧，以使每個由“ B”發送的頁面都可以（這是您的應用程序連接到Facebook的方式，每個頁面加載時都有一個Facebook調用）。這確實給您增加了壓力擁有自己的服務器。

  • 或者，您可以獨立跟蹤服務器“ B”上的會話“ Y”，並假定用戶已登錄，直到服務器“ A”與您聯系，說與會話“ X”關聯的用戶（並因此與會話“ Y”關聯） ）已注銷-然后您也將用戶從會話“ Y”注銷。

  • 您也可以使用“服務器到服務器”調用來共享活動（例如，“與“ X”關聯的用戶已獲得成就，更新本地緩存”，或“與“ Y”關聯的用戶已注銷-注銷“ X”也'）。 我還通過Javascript調用來備份這一頁，因此，如果我在兩個選項卡中查看兩個頁面，其中一個位於服務器“ A”上

並且一旦從服務器“ B”退出，如果我注銷了一個，則Javascript調用將定期檢查並使我退出另一個。

那么，安全嗎？

“ X”和“ Y”都是公共字符串。 這意味着，如果您盜取“ Y”，則可以冒充“ X”。 實際上，這與竊取普通會話密鑰“ X”沒有什么不同，但是您可以做更多的事情來防止欺騙。 您知道，對“ A”的iFrame調用應該來自完全相同的IP，用戶代理和引薦來源網址[注2]，並且iFrame調用應該與“ B”的請求大約同時出現（給定或獲取網絡延遲，請等待30秒）。 如果任何一個都不匹配，則放棄會話“ Y”，創建一個新的會話“ Y”，然后重新開始“會話”（Y）和“ X”相同的過程。

接下來呢？

您可以執行多種操作，並且可能需要進行調整以獲得所需的確切流程。 您也可以使用同一系統登錄到多個應用程序（例如，我擁有Wordpress，SMF和一個自定義游戲，它們都共享數據，因此即使應用程序位於不同的服務器上，您也可以登錄一個並在另一個上注銷），但是共享域，因此可以共享cookie，這使操作變得容易一些，但它們不共享會話，因此我采取了這種措施。 但是，作為最終用戶，除了“重定向頁面”或暫時的“您尚未登錄”外，他們應該不會注意到。

另一種變化是服務器“ A”還可以加載隱藏的iFrame，該隱藏的iFrame可以在服務器“ B”上加載頁面。 同樣的溝通，只是相反。 由於用戶無法訪問“ A”才能登錄，因此iFrame將在用戶登錄之前鏈接“ X”和“ Y”，這是不可避免的。 因此，當用戶從服務器“ B”訪問頁面時，“ X”和“ Y”已鏈接，我們立即知道它們是否已登錄。 但是，您仍然需要輪詢，因此並沒有使輪詢變得容易。

筆記：

注意1：使用javascript選項時，請小心。 我寫的一個系統太忙了，以至於服務器無法應付（這分散在5台服務器上）。 javascript沒有得到響應，但是進行了嘗試，這增加了負載。 這意味着服務器->服務器之間的通信均無法通過，並且由於使用了所有Apache套接字，它很快使整個系統崩潰。 Javascript不斷進行輪詢和輪詢，即使系統關閉后，瀏覽器仍在繼續運行（當然）。 我們必須對舊的調用URL進行黑洞處理，更新該調用以響應其他URL，並以某種方式使所有用戶的瀏覽器獲得新的Javascript，以便它們能夠正常運行。 因此，如果您選擇輪詢路線，請為此方案做好計划。

注意2：通常，您不應該完全依靠這些來驗證用戶，因為它們很容易被更改/欺騙。 但在這種情況下，它們應該完全相同，並且非常適合確認用戶沒有嘗試做有趣的事情。

注意3：這是對單一登錄解決方案的建議，其解決方案已在多個站點上實現。 我不是要就每種方法的各種優點，嚴重的負載，陷阱或潛在的安全漏洞等問題進行辯論。 當您實施時，它們供您考慮。 您將在此過程中發現一些陷阱。

Answer 2

是的，只要這3個網站在同一域中，就可以。 如果不是，則不會將網站1創建的cookie發送到網站2。

Answer 3

我最近發布了一個新產品，該產品被稱為“單點登錄服務器/客戶端”：

http://barebonescms.com/documentation/sso/

現在只有一個PHP服務器和客戶端。 如果您有興趣使用它，則最有意義的是將服務器部分安裝在PHP主機上。 然后，需要進行一些移植工作才能獲得ASP.NET和JSP的有效客戶端。 但是它確實可以跨域工作。 我應該警告您，當前，每個客戶端實例都需要再次登錄。