保護有狀態的Web服務

Question

我們正計划開發一層REST服務，以公開遺留系統上托管的服務。 這些服務將由經典Web應用程序和本機移動電話應用程序使用。

這種遺留系統的安全性使得需要初始用戶名+密碼驗證（一個可能需要5到10秒的過程）。 初始身份驗證后，將返回時間受限的令牌。 然后，此令牌必須包含在所有其他請求中，否則請求將被拒絕。

由於安全性要求，無法在REST服務層之外返回舊安全令牌。 這意味着REST服務層需要將此令牌保留在某種形式的用戶會話中，否則每次調用遺留系統時都需要重復昂貴的用戶名+密碼身份驗證過程。

REST服務層將使用Java 6 + Spring 3 + Spring Security 3堆棧實現。 乍一看，看起來這個設置運行正常：基於Spring的REST服務將使用相當標准的Spring Security配置進行保護，舊的安全令牌將存儲在用戶的HTTP會話中，並且每個調用都將使用用戶的會話並將其發送到舊系統。

但問題在於：REST客戶端將如何發送必要的數據，以便正確檢索用戶的HTTP會話？ 這通常由Web瀏覽器使用JSESSIONID cookie透明地完成，但此過程中不涉及任何瀏覽器。 當然，REST客戶端可以在其代碼中添加cookie管理，但對於所有Spring RestTemplate，iPhone，BlackBerry和Android客戶端來說，這是一項簡單的任務嗎？

另一種方法是繞過REST服務層的HTTP會話，並使用其他形式的用戶會話，可能使用數據庫，使用REST客戶端通過HTTP頭或簡單請求查詢發送的密鑰來識別。 接下來的問題是，Spring Security如何配置為使用這種備用會話機制而不是標准的Servlet HttpSession？

當然，我不是第一個處理這種情況的人。 我錯過了什么？

謝謝！

Answer 1

餅干沒什么神奇之處。 它們只是HTTP標頭中的字符串 。 任何體面的客戶端API都可以處理它們，盡管許多客戶端需要顯式配置才能啟用cookie處

使用cookie的另一種方法是將JSESSIONID放入URL中。 我對spring-security一無所知，但看起來這實際上是至少某些類型的URL請求的默認值，除非disable-url-rewriting明確地設置為true。 不過，這可以被視為安全漏洞 。

Answer 2

不幸的是，身份驗證很成問題 - 在Web標准和瀏覽器實現方面有點盲點。 你是對的，cookie不被認為是“RESTful”，而是純粹主義者，但即使在功能齊全的瀏覽器上也避免了相當多的hackery，如本文所述： 基於Rest的身份驗證 。

不幸的是，我沒有做過任何移動開發，所以我不能建議最好的妥協是什么。 你可能想通過檢查什么您的每一個針對性的平台的驗證模型不支持啟動。 特別是，兩個主要選項是：

• HTTP身份驗證（理想情況下是“摘要”，而不是“基本”）
• 餅干

一種可能性是提供兩種選擇。 從技術或安全的角度來看，顯然不是理想的，但在可用性方面可能有優點。