J'essaie d'intégrer Spring Security SAML Extension with Spring Boot.
À ce sujet, j'ai développé un exemple d'application complet. Son code source est disponible sur GitHub:
En l'exécutant en tant qu'application Spring Boot (exécutée sur le serveur d'applications intégré du SDK), la WebApp fonctionne correctement.
Malheureusement, le même processus AuthN ne fonctionne pas du tout sur Undertow/WildFly .
Selon les journaux, l'IdP effectue réellement le processus AuthN : les instructions de mon implémentation personnalisée UserDetails
sont correctement exécutées. Malgré le flux d'exécution, Spring ne configure pas et ne conserve pas les privilèges de 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;
}
}
Lors du débogage, j'ai découvert que le problème dépend de la classe FilterChainProxy
. Au moment de l'exécution, l'attribut FILTER_APPLIED
de ServletRequest
a une valeur null, donc 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 VMware vFabric tc Sever et Tomcat , tout fonctionne parfaitement. Avez-vous une idée de la résolution de ce problème?
En enquêtant sur le problème, j'ai remarqué qu'il y avait des problèmes avec les cookies et les référents dans la demande d'authentification.
Actuellement, l'authentification Wildfly fonctionnera si vous changez le contexte de l'application Web en contexte racine:
<server name="default-server" default-Host="webapp">
<http-listener name="default" socket-binding="http"/>
<Host name="default-Host" alias="localhost" default-web-module="sso.war"/>
</server>
Après avoir redémarré Wildfly et effacé les cookies, tout devrait fonctionner comme prévu