spring安全過濾器應該直接調用身份驗證提

Question

似乎有兩種不同的模式：

模式＃1
GenericFilterBean自己進行身份驗證。 正如大多數開箱即用的過濾器所使用的： UsernamePasswordAuthenticationFilter ， DigestAuthenticationFilter等。

請求進入過濾器

filter使用authenticated=false創建Authentication authenticated=false

filter將其傳遞給它直接引用的特定 AuthenticationProvider （有時通過AuthenticationManager ）

如果一切順利，他們會創建一種新的Authentication並傳回過濾器

filter將其放入上下文中

在這種模式中，原始Authentication只不過是傳遞給AuthenticationProvider的POJO - 它永遠不會進入上下文。
此外，過濾器通常也直接引用特定的EntryPoint - 它最后調用它。
（我認為這種模式適合預身份驗證過濾器？但Spring代碼中沒有那種一致性）。

模式＃2
單獨注冊的AuthenticationProviders進行身份驗證。 正如大多數在線示例所使用的那樣，但在開箱即用的過濾器中很少見到。

請求進入過濾器

filter使用authenticated=false創建Authentication authenticated=false

filter將其放入上下文中。

過濾器的工作完成了

spring security現在運行所有已注冊的AuthenticationProviders

其中一個接受此Authentication並嘗試驗證它

如果一切順利，他們會將Authentication變為authenticated=true

在此模式中，篩選器不直接調用AuthenticationProvider或EntryPoint 。 這些是在外部注冊的，適用於所有過濾器。 模式＃2配置的典型示例：

 <sec:http use-expressions="true" entry-point-ref="myCustomEntryPoint" pattern="/**"> <sec:custom-filter before="FILTER_SECURITY_INTERCEPTOR" ref="myCustomFilter" /> ... </sec:http> <sec:authentication-manager> <sec:authentication-provider ref="myCustomAuthenticationProvider" /> </sec:authentication-manager> 

問題： 何時使用一種方法或另一種方法是否有任何邏輯？

模式＃2 感覺最好。 但我認為無論哪種方式都有效，並且我不確定哪種方式正確/最佳/最安全/最具前瞻性/最不可能與其他過濾器等沖突。

如果上下文很重要，那就是Spring Security 3.2.5，它將用於基於令牌的身份驗證，我們在授予訪問權限之前驗證對遠程服務的令牌詳細信息（取自請求標頭）。

Answer 1

已經3年了，所以我認為結論是沒有正確或錯誤的方式！

Spring Security的內容並沒有太大變化，因為它是Acegi，它似乎是不同方法的混合。

最后，我選擇了模式＃1。 我不喜歡這樣的事實：Pattern＃2使用了從authenticated = false到true的神奇變化的可變對象！

模式＃1允許我使用兩個不可變對象（一個始終驗證為false，另一個始終驗證為true - 但僅在成功時添加），這實際上感覺更安全。