我有一个独特的场景，我想在Spring Security插件的约束下进行解决（如果是currcurr，则为1.2.7.3版）。我创建了一个自定义SSO插件，该插件允许使用签名的URL登录。自定义插件的效果很好，根据文档，我通过在resources.groovy中创建bean并将其添加到BootStrap.groovy中的过滤器链中进行了添加。
SpringSecurityUtils.clientRegisterFilter('ssoFilter', SecurityFilterPosition.SECURITY_CONTEXT_FILTER.order + 10)
用户登录后，一切都会很好，添加到安全上下文中的现有活动会话将对用户进行身份验证。
我有一个用例，一个已经通过身份验证的用户可能会与一个SSO请求上的另一个用户一起回到同一浏览器（即，相同的会话cookie）。我想让过滤器链在URL的查询字符串中注意到'sso = true'。
我现在看到的行为是从未达到SSO，因为原始用户已经通过安全上下文进行了身份验证。我无法在SecurityContextPersistenceFilter之前添加SSO过滤器，因为这会导致SSO过滤器不断被击中而实际上未呈现任何内容的问题。在我看到它的文档之后，我说您不应在安全上下文过滤器之前放置任何过滤器。
我已经研究过使用springsecurity.filterChain.chainMap配置说，专门为带有'sso = true'的URL创建特殊的过滤器链（我在未经身份验证的流程中通过将自定义RequestMatcher和AuthenticationEntryPoint实现添加到DelegatingAuthenticationEntryPoint来执行此操作）。但是，从文档和实验来看，只有路径被过滤。
有没有一种方法可以确保只要在URL上看到“ sso = true”，都可以命中SSO筛选器，同时仍然对安全上下文具有可用性，或者可以确保SecurityContextPersistenceFilter可以将请求传递给SSO筛选器？
在我看来，您可以使用风俗习惯SecurityContextRepository。
Spring Security Grails插件的1.2.7.3版本似乎使用的是Spring Security 3.0.7。如Spring Security参考资料的第8.3.1节所述，从Spring Security 3.0开始，将SecurityContextPersistenceFilter使用SecurityContextRepositoryBean来配置，该bean负责加载和保存SecurityContext。默认情况下，这是的实例HttpSessionSecurityContextRepository。
您可以创建一个扩展的自定义类HttpSessionSecurityContextRepository。如果请求包含sso=true查询参数，则自定义子类可以重写loadContext（HttpRequestResponseHolder）方法以删除“ SPRING_SECURITY_CONTEXT”会话属性。
您可以HttpSessionSecurityContextRepository在GitHub上查看Spring Security 3.0.7的实现：https :
//github.com/spring-projects/spring-security/blob/3.0.7.RELEASE/web/src/main/java/org/springframework /security/web/context/HttpSessionSecurityContextRepository.java
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句