Je travaille afin d'intégrer Spring Security SAML Extension avec Spring Boot.Spring Security sur wildfly/Undertow: erreur exécution de la chaîne de filtrage
I a développé une application complète de l'échantillon, tout le code source est publié sur GitHub:
En exécutant l'application Web que l'application Spring Boot (par Spring Set Tool, par en utilisant un serveur d'applications intégré), cela fonctionne très bien. Malheureusement, le processus d'authentification ne fonctionne pas sur Undertow/WildFly (et je dois l'utiliser comme AS de production). En enregistrant, je peux voir que l'IdP exécute le processus AuthN et les instructions de mon implémentation personnalisée UserDetails sont correctement exécutées. Malgré cela, Spring ne définit pas les privilèges pour l'utilisateur actuel.
@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("[email protected]") != 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;
}
}
Par débogage, j'ai vérifié que le problème commence à partir de la classe FilterChainProxy. Lorsque je lance la webapp sur WildFly, je peux voir que l'attribut FILTER_APPLIED de ServletRequest est nul, ainsi Spring efface le 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);
}
}
Sur Sever VMware vFabric tc et Tomcat qui ne se produit pas. Existe-t-il un moyen de résoudre ce problème?
Dans la plupart des situations, le 'SecurityContextHolder' devrait être effacé après une demande. Le seul but de ce code est dans le cas où la chaîne de filtres est appliquée plus d'une fois pendant la même requête (dans ce cas, seule la chaîne d'origine doit effacer le contexte). Donc, je ne pense pas que ce soit un problème. –
BTW, ce comportement invalide le processus de connexion à chaque fois. Y at-il un moyen de le réparer, par exemple en configurant correctement mon logiciel de l'AS? – vdenotaris
Je ne sais pas ce que vous voulez dire par là. Quel comportement, et comment cela invalide-t-il la connexion? Effacer le contexte lorsqu'un thread termine la gestion d'une requête est un comportement normal - il est essentiel d'empêcher la fuite de données locales de threads vers un pool de threads. À ce stade, le contexte doit généralement être mis en cache dans la session de l'utilisateur. Cela ne devrait donc pas invalider un identifiant. –