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 - 但仅在成功时添加），这实际上感觉更安全。