春季安全Kerberos鏈接基本

Question

我對Spring Security有一個希望很快的問題。

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

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

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

感謝輸入

Answer 1

由於這個問題是有點困難，我假設你已經熟悉展示瞭如何配置Kerberos身份驗證與表單身份驗證作爲後備的Spring Security Kerberos samples。 我沒有證據表明它會起作用，但我認爲你應該可以用基本身份驗證鏈接你的kerberos身份驗證而沒有任何問題。我分享這個我的想法......

思想1：FilterChains

支持多張認證方法的關鍵是要正確設置認證過濾器的順序。 如果順序錯誤，客戶端可能會掛起基本身份驗證，並且可能永遠不會到達Kerberos身份驗證篩選器，因爲瀏覽器的基本身份驗證對話框會彈出。這可能取決於Spring的基本身份驗證提供程序和過濾器是如何實現的。無論如何，如果訂單是正確的，kerberos過濾器（基本認證過濾器）後的鏈中過濾器將開始其工作。

思考2：Kerberos的身份驗證不應該打破基本身份驗證

瀏覽器應該用對待與基本身份驗證提供者的通信不同的Kerberos服務提供者的通信，因爲協議是不同的。 SAML通信在it's own namespace中運行，因此我認爲它不應該影響基於HTTP標頭中授權元素的基本身份驗證通信。

編輯：即使關於命名空間不打在瀏覽器行爲的任何角色的假設，步驟6 sequence diagram將是一個關鍵點。當篩選器鏈接正確時，Spring應該返回一個401響應，如401 - Access denied - WWW-authenticate - Basic realm = "your domain"這將強制您的瀏覽器進入基本身份驗證。

思想3：SPNEGO協商Spring Security的Kerberos的

Spring Security的Kerberos文檔是實際上可以建立在這些想法中的Spnego configuration。這也可以在樣本中看到，在第49和50行this WebSecurityConfig.java

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

最後一個思想

如果沒有要求強迫你做一個基本的身份驗證，我會建議不使用它。最好使用基於令牌的身份驗證。即使我不完全同意這個博客的所有細節，它也會解釋why basic auth shouldn't be used，如果你可以避免的話。

Answer 2

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

最終這個工作;但我會解釋一些我堅持的觀點。

我使用請求匹配的我的呼叫劃分成不同HTTP configuration blocks

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

然後，爲了2，我配置了一個塊來處理Kerberos。在與Kerberos提供者配置摔跤並提出了一個在我們的底層系統中進行身份驗證的方案後，這一切都得到了很好的處理。從Kerberos獲取連接到我的網絡應用程序的域用戶的用戶名後，我查看了該用戶名是否在我的系統中。如果他們是，我們登錄他們。如果不是，我們將他們引導到登錄頁面。 （不是每個域用戶都被授權使用我們的網絡應用程序，即使它們已通過身份驗證）

然後最後，最後一塊被配置爲表單身份驗證。

但有一些困難點。

• 我必須爲我的自定義基本/表單和Kerberos提供程序全局配置身份驗證管理器。
• 而且作爲一個便箋，我確實必須配置我的認證管理器bean，如this link suggests。可能是由於我創建的xml/java配置的拼湊在一起的shamble。
• IE也很奇怪。在我的kerberos鏈中，我還配置了登錄表單。這使得有資格獲得鏈的用戶可以直接導航到登錄表單進行身份驗證;或者如果有人失敗了我的Kerberos用戶名檢查，我可以將它們轉發到登錄頁面。這與FireFox一起工作良好，但即使在我的服務器發送重定向後，IE仍繼續發送協商標題。基本上，用戶失敗kerberos，重定向到登錄頁面，但IE依然發送Kerberos令牌。這會導致Spring Security的SpnegoAuthenticationProcessingFilter再次觸發並驗證Kerberos令牌，當然這會再次失敗，並向用戶發送繼續循環的登錄頁面。

總之春季安全進行3不錯，還算乾淨塊，所有做各種不同的認證/授權，然後一前一後的所有作品，提供相同的用戶上下文對象我們的Web應用程序。