Spring Security Kerberos鏈接基本

Question

我有一個關於Spring Security的快速問題。

我正在尋找一種解決方案，將安全性集成到我們的應用程序中，該應用程序提供SSO但HTTP基本也是如

我們系統的一個自動化部分只能支持基本身份驗證，我們非常關注它。 目前我們的目標是將Kerberos用於我們的SSO解決方案，然后還支持基本（非常有限的使用）。 所有這些都將保護通過resteasy運行的RESTful Web服務。

有沒有人在彈簧安全鏈接的Kerberos和BASIC解決方案中看到任何固有的不可能性？ 我們遇到了WildFly的問題，並且無法支持多種不同的身份驗證方法，這些方法在握手時使用HTTP響應代碼。

感謝您的投入

Answer 1

由於這個問題有點困難，我假設您已經熟悉了Spring Security Kerberos示例 ，它們展示了如何使用表單auth配置kerberos auth作為回退。 我沒有證據表明它會起作用，但我認為你應該能夠用基本的auth鏈接你的kerberos auth而沒有任何問題。 我分享了我對此的看法......

思想1：FilterChains

支持多種身份驗證方法的技巧是正確設置身份驗證篩選器的順序。 如果訂單錯誤，客戶端可能會掛起基本身份驗證，並且可能永遠不會到達kerberos身份驗證過濾器，因為會彈出瀏覽器的基本身份驗證對話框。 這可能取決於如何在Spring中實現基本身份驗證提供程序和過濾器。 無論如何，如果訂單是正確的，那么在kerberos過濾器（基本認證過濾器）之后的鏈接中的下一個過濾器將開始工作。

思想2：Kerberos auth不應該破壞基本身份驗證

瀏覽器應該將與kerberos服務提供商的通信視為與基本auth提供商的通信不同，因為協議是不同的。 SAML通信在其自己的命名空間中運行，因此在我看來它不應該影響基於HTTP頭中的授權元素的基本身份驗證通信。

編輯： 即使關於命名空間的假設在瀏覽器行為中沒有任何作用， 序列圖中的步驟6也將是關鍵點。 當過濾器鏈接正確時，Spring應該返回401響應，如 401 - Access denied - WWW-authenticate - Basic realm = "your domain" ，這將強制您的瀏覽器進入基本身份驗證。

思想3：Spnego在Spring Security Kerberos中進行談判

Spring Security Kerberos文檔中的Spnego配置是基於這些想法的。 這也可以在WebSecurityConfig.java的第49行和第50行的示例中看到

如果遇到麻煩我會感到驚訝。

最后一個想法

如果沒有要求強迫您進行基本身份驗證，我建議不要使用它。 更好地保持基於令牌的身份驗證。 即使我不完全同意這個博客的所有細節，它解釋了為什么不應該使用基本身份驗證 ，如果你可以避免它。

Answer 2

我強烈建議你閱讀Mika的答案。 它做得非常好，讓我有信心向前邁進。

最終這有效; 但我會解釋一下我的幾個難點。

我使用Request matcher將我的調用分成不同的HTTP配置塊

在第1順序中，我配置了一個塊來過濾來自特定工具的請求，由用戶代理進行過濾。 在該塊中，我基本上以標准OOTB方式配置了基本認證。 我確實編寫並提供了自己的身份驗證提供程序，此提供程序調用了我們用於通過用戶名/密碼管理用戶的基礎系統。

然后，按順序2，我配置了一個塊來處理Kerberos。 在與Kerberos提供程序配置進行搏斗並提出在我們的底層系統中進行身份驗證的方案之后，這一切都處理得很好。 從Kerberos獲取連接到我的Web應用程序的域用戶的用戶名后，我檢查了該用戶名是否在我的系統中。 如果是，我們將其登錄。如果沒有，我們將它們引導到登錄頁面。 （並非每個域用戶都有權使用我們的Web應用程序，即使他們已通過身份驗證）

最后，最后一個塊配置為表單身份驗證。

但有一些問題。

• 我必須為我的自定義基本/表單和Kerberos提供程序全局配置身份驗證管理器。
• 另外，作為旁注，我必須像我的鏈接建議那樣配置我的身份驗證管理器bean。 可能是由於我創建的xml / java配置的拼湊在一起的shamble。
• IE也很奇怪。 在我的kerberos鏈中，我還配置了一個登錄表單。 這允許符合鏈條資格的用戶直接導航到登錄表單進行身份驗證; 或者，如果有人通過我的Kerberos用戶名檢查失敗，我可以將它們轉發到登錄頁面。 這與FireFox一起工作正常，但即使我的服務器發送了重定向，IE仍繼續發送Negotiate標頭。 基本上用戶失敗kerberos，獲得重定向到登錄頁面，但IE仍然發送Kerberos令牌。 這會導致Spring Security的SpnegoAuthenticationProcessingFilter再次觸發並驗證Kerberos令牌，當然這會再次失敗，並向用戶發送繼續循環的登錄頁面。

總而言之，Spring Security允​​許3個不錯的，相當干凈的塊，它們都進行各種不同的身份驗證/授權，然后它們協同工作以向我們的Web應用程序提供相同的用戶上下文對象。