Question

似乎有两种不同的模式：

模式＃1
GenericFilterBean进行身份验证。正如大多数现成的过滤器所使用的那样：UsernamePasswordAuthenticationFilter，DigestAuthenticationFilter等。

请求进入过滤器

过滤器使用Authentication创建authenticated=false

过滤器将其传递给它直接引用的特定 AuthenticationProvider（有时通过AuthenticationManager）

如果一切顺利，他们会创建新类型的Authentication并传回过滤器

过滤器将其放入上下文

在这种模式中，原始的Authentication只不过是传递给AuthenticationProvider的POJO - 它永远不会进入上下文。
此外，过滤器通常也会直接引用特定的EntryPoint - 它最后会调用它。
（我认为这种模式适合预身份验证过滤器？但Spring代码中没有这种一致性。）

模式＃2
单独注册AuthenticationProviders进行身份验证。正如大多数在线示例所使用的那样，但在开箱即用的过滤器中很少见到。

请求进入过滤器

过滤器使用Authentication创建authenticated=false

过滤器将其放入上下文中。

过滤器的工作已经完成

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。我不喜欢这样的事实，即模式2使用了可变的对象，这些对象神奇地从authenticated = false更改为true！

模式1使我可以使用两个不可变的对象（一个总是被认证为false，另一个总是被认证为true-但仅在成功时添加），这实际上使人感到更加安全。

spring安全过滤器应该直接调用身份验证提

1 个答案: