題:
同一Web應用程序上下文中的多個系統/平台之間的身份驗證
yojimbo87
2011-09-12 20:14:10 UTC
view on stackexchange narkive permalink

請考慮以下情形： Web應用程序正在使用兩個單獨的系統（它們可以通過DB共享數據/狀態）。第一個用於處理標準的Web內容，例如HTTP請求/響應，HTML內容，表單以及所有相關內容。第二個用於實時通信，例如發送消息和通知（長時間輪詢或WebSocket服務器）。

可以通過第一個系統/平台對用戶進行身份驗證，如果憑據有效，則會將某些網頁發送回客戶端。加載此頁面後，客戶端應在後台與第二個系統/平台透明連接。

問題是：如何在網頁/應用程序上對用戶進行身份驗證

我可以這樣想像：

  1. 通過第一個系統/平台對用戶進行身份驗證時，GUID令牌是生成並存儲在與某些用戶綁定的數據庫中。此令牌和用戶ID也會作為響應發送回客戶端，例如，呈現在頁面上的隱藏字段中。
  2. 加載頁面並與第二個系統/平台建立連接時從隱藏字段中獲取位置，令牌和用戶ID，並將其作為參數發送給連接請求。後端找到用戶，在數據庫中比較其令牌，如果它們與實時連接匹配，則可以啟動。
    3. ol>

    我知道這種方法很容易被嗅探，但是我我對兩個分離的系統/平台之間的身份驗證過程很感興趣。

請參見此處的示例。https：//www.login.mtu.edu/docs/public/mtuiso/howitworks2.html待會兒我會回答。
“在頁面上的隱藏字段中呈現”似乎是個壞主意。
@this.josh：是的，我真正的意思是將這些信息存儲在客戶端上的某個地方，不必是隱藏字段，它可以是cookie ...
一個基本的問題是兩個系統是否正在提供來自同一域（例如www.example.com/a和www.example.com/b）的網頁；來自兩個相關的域（例如a.example.com和b.example.com）；或兩個不相關的域（例如a.com和b.com）。這影響了什麼解決方案是可行的還是不可行的。
三 答案:
Jeff Ferland
2011-09-12 20:24:12 UTC
view on stackexchange narkive permalink
  • 登錄時生成會話令牌。
  • 將該會話令牌存儲在數據庫中。
  • 在身份驗證時檢查有效的會話令牌。

您所擁有的幾乎全部。只要考慮一下您是否想一次擁有多個有效會話，以及如何終止會話即可。

編輯下面的瘋狂評論線程

雖然可以向客戶端提供經過第二服​​務器驗證的令牌，而無需與第一服務器進行通信，但這很醜陋，並且涉及很多工作。這種情況不允許客戶端使會話無效，除非客戶端負責。傳遞令牌時還需要一定的時間窗口，令牌的時間戳，第二系統對令牌的跟踪，令牌傳遞中的簽名或HMAC等。除非這兩個系統在Internet上無法互相看到，否則請避免

我認為這兩個系統都可以訪問相同的數據庫，但是如果由於某些原因它們無法訪問，則將第二個系統公開的API可以遠程驗證也很合適（

如果沒有SSL，則無法採取任何措施通過Firesheep / MITM攻擊來防止會話劫持。

我還需要介紹例如從多個瀏覽器對用戶進行身份驗證或實時連接丟失並需要重新啟動的情況（我想到這裡可能發生的一個問題-我會將過期令牌傳遞給第二個系統，因此身份驗證將失敗）。
設計您的架構，使身份驗證令牌位於其自己的表中，並通過用戶ID與用戶表連接。主鍵（user_id，令牌）。然後，您可以有多個有效的會話。您可能還需要添加由應用程序檢查的到期時間戳記，並具有cron作業以刪除過期的令牌。
我想到的其他解決方案是：加載頁面時，將AJAX令牌請求發送到第一個系統，並在此AJAX調用的成功回調中將令牌傳遞到第二個系統連接請求。這樣，就無需在隱藏字段中存儲令牌或用戶ID。
編輯：沒關係；您不想這樣進行身份驗證。客戶端不應該有這樣的東西。我知道執行此操作的正確方法，但我不知道具體細節。我會進行研究並與您聯繫。
您將如何防止重放攻擊？您如何使註銷會話無效？處理斷開的會話？可以通過客戶端工作來做到這一點，但是如果走那條路，您會為自己帶來更大的頭痛。
@user606723:，但是為了驗證綁定到某個會話的用戶，您不是必須從客戶端向第二個系統發送一些東西嗎？
您是對的，我想我是一個很大的愛好，您必須從客戶端發送一些信息。 Cookie是一個不錯的選擇。如果不是cookie，則使用私鑰進行簽名。
同樣，傑夫·費蘭德（Jeff Ferland）提出的建議的問題是，這假定應用程序具有某種實時通信，例如公共數據庫。我認為這是一個錯誤的現實世界假設。
@user606723如果不是數據庫，則使用某種編程API。需要解決我最近的評論中的問題。沒有某種形式的交流，系統就無法做到這一點。
僅當您已經通過第一個系統的身份驗證時，才會返回該AJAX調用中的@Jeff Ferland:令牌。每次您進行此調用時，此AJAX還將返回全新的令牌（服務器上還將帶有時間戳）。因此，例如，如果您嘗試在15秒後使用相同的令牌進行連接，則該令牌將無效，因此您必須請求新的令牌。這種方法仍然無效嗎？
@yojimbo,第二個應用程序如何知道它是有效令牌？他們共享數據庫嗎？
@Jeff,看到了我的答案。
@user606723:是的，他們倆都可以訪問後端的同一數據庫以共享狀態和其他內容。
問題是，這使得中間人攻擊非常容易。我要做的就是獲得令牌並在15秒內做出響應？十分簡單。您可以做一些事情來解決這個問題，使它“幾乎是有效的”，但這絕不是一種最佳方法。
@user606723:我認為，如果您進行中間人攻擊，則可以從第一個系統劫持整個會話，而不必與第二個系統打交道。據我所知，只有HTTPS可以阻止這種情況。
user606723
2011-09-12 23:41:58 UTC
view on stackexchange narkive permalink

我的建議是使用一個用於主要用戶身份驗證的Web應用程序。

注意：由於Cookie的性質，該方法僅在Web應用程序共享公共域時才有效。 （即appone.example.com和apptwo.example.com）。
openid可以執行類似的操作，但是繞過了cookie問題，您可能想了解一下。

這將如何工作

  1. 用戶將瀏覽器指向AppA。AppA檢查有效的cookie /會話/其他內容。
    1. 首先檢查其自己的會話/ cookie信息。
    2. 。如果找不到它自己的cookie，它將查找Auth App的“傳輸” cookie。
      1. 如果找到，則為該應用創建一個新會話。用戶剛剛登錄。
        2. ol>
      3. ol>
  2. 當發現該用戶名無效或丟失時，會將頁面轉發到Auth App。
    3. >
  3. Auth App會在其末尾檢查是否有有效的會話。
    1. 當發現缺少該會話時，會顯示一個登錄屏幕，等等。
      2. ol>
  4. 具有有效會話的Auth應用程序將為該應用程序設置一個特定的“傳輸” cookie，並將該人重定向回應用程序A。
    5. ol>

    您應在其中添加其他信息此類傳輸cookie，例如-

    1. 用戶名
    2. AuthTime
    3. IP地址。
    4. 隨機數。
      5. ol>

      請參見以下示例。 https://www.login.mtu.edu/docs/public/mtuiso/howitworks2.html

      從用戶的角度來看這幾乎是看不到的。例如。

      1. 用戶將瀏覽器指向應用A。
      2. 應用A確實使用Auth App進行身份驗證。 （要求用戶登錄等）。
      3. 用戶單擊轉發到應用程序B的鏈接。
      4. 應用程序B與Auth App進行身份驗證。 （這一次Auth應用本身已經具有cookie。）
        1. App B轉發到Auth App。
        2. Auth App找到cookie，然後立即創建傳輸cookie並轉發到App B
        3. 用戶甚至沒有註意到這一點，並立即在App B中發現自己。
          4. ol>
        5. ol>
Sachin Kumar
2011-09-22 14:44:18 UTC
view on stackexchange narkive permalink

四個選項，第一個是成本（金錢和性能都最高），第三個是最便宜的

  1. 部署Siteminder，Novell，Tivoli等解決方案

    li>

  2. 維護數據庫中的會話狀態。為此。這種方法的問題在於，將很難跟踪註銷，會話到期以及在兩個應用程序之間傳播此信息。因為在每個請求之前查詢數據庫會非常昂貴

  3. 使用第三個應用程序來管理會話狀態。此應用程序不只向最終用戶開放，僅在網絡中受限制，只能訪問兩個應用程序。它在應用程序上下文中存儲所有用戶的狀態，並且兩個應用程序向該應用程序發送請求

    On登錄事件關於註銷事件關於會話到期事件，在處理任何檢查會話有效性的請求之前

  4. 使用cookie（假設兩個應用程序共享相同的父域）

    創建一個包含用戶名+ salt / ecret密鑰的cookie，此加密的Secret密鑰和加密密鑰都與兩個應用程序一起使用來自用戶的任何請求都將攜帶此cookie（Cookie路徑設置為/）因此，如果Cookie包含用戶名，則其他應用程序會信任用戶在其他應用程序上登錄

    5. ol>


ⓘ
該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到，我們感謝它分發的cc by-sa 3.0許可。
Loading...