我正在尝试将Spring Security SAML Extension与Spring Boot集成在一起。
关于此事，我确实开发了完整的示例应用程序。其源代码可在GitHub上找到：
通过将其作为Spring Boot应用程序运行（针对SDK内置的Application Server运行），WebApp可以正常工作。
不幸的是，相同的AuthN进程在Undertow / WildFly上根本不起作用。
根据日志，IdP实际上执行AuthN过程：我的自定义UserDetails实现的指令已正确执行。尽管有执行流程，Spring仍未设置并保留当前用户的特权。
@Component
public class SAMLUserDetailsServiceImpl implements SAMLUserDetailsService {
// Logger
private static final Logger LOG = LoggerFactory.getLogger(SAMLUserDetailsServiceImpl.class);
@Override
public Object loadUserBySAML(SAMLCredential credential)
throws UsernameNotFoundException, SSOUserAccountNotExistsException {
String userID = credential.getNameID().getValue();
if (userID.compareTo("jdoe@samplemail.com") != 0) { // We're simulating the data access.
LOG.warn("SSO User Account not found into the system");
throw new SSOUserAccountNotExistsException("SSO User Account not found into the system", userID);
}
LOG.info(userID + " is logged in");
List<GrantedAuthority> authorities = new ArrayList<GrantedAuthority>();
GrantedAuthority authority = new SimpleGrantedAuthority("ROLE_USER");
authorities.add(authority);
ExtUser userDetails = new ExtUser(userID, "password", true, true, true,
true, authorities, "John", "Doe");
return userDetails;
}
}在调试时，我发现问题取决于FilterChainProxy类。在运行时，该属性FILTER_APPLIED的ServletRequest有一个空值，从而春清除SecurityContextHolder。
private final static String FILTER_APPLIED = FilterChainProxy.class.getName().concat(".APPLIED");
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
boolean clearContext = request.getAttribute(FILTER_APPLIED) == null;
if (clearContext) {
try {
request.setAttribute(FILTER_APPLIED, Boolean.TRUE);
doFilterInternal(request, response, chain);
} finally {
SecurityContextHolder.clearContext();
request.removeAttribute(FILTER_APPLIED);
}
} else {
doFilterInternal(request, response, chain);
}
}在VMware vFabric tc Sever和Tomcat上，一切正常。您有解决此问题的想法吗？
顺便说一句，此行为每次都会使登录过程无效。是否有办法解决该问题，例如通过正确配置AS的软件？
—
vdenotaris 2014年
不知道这是什么意思。什么行为，以及如何使登录无效？线程完成对请求的处理后清除上下文是正常行为-防止线程本地数据泄漏回线程池非常重要。那时，上下文通常应该缓存在用户的会话中。因此，它不应使登录无效。
—
肖恩·绵羊
如上所述，在SSO之后，应用程序服务器清除会话数据和身份验证数据。仅在Wildfly中会发生这种情况：相同的代码在Tomcat中可以正常工作。
—
vdenotaris 2014年
SecurityContextHolder.clearContext()不会清除会话数据。在将ThreadLocal线程释放回线程池之前，它将删除上下文的存储。我的观点是，这应该总是在请求结束时发生，因此您看到的是正常现象，不太可能成为问题的原因。
SecurityContextHolder应在请求后清除。该代码的唯一目的是在同一请求期间多次应用过滤器链的情况（在这种情况下，只有原始链应清除上下文）。所以我认为这不是问题。