Spring Security su Wildfly: errore durante l'esecuzione della catena di filtri

194

Sto cercando di integrare l' estensione SAML di Spring Security con Spring Boot .

A proposito, ho sviluppato un'applicazione di esempio completa. Il suo codice sorgente è disponibile su GitHub:

Integrazione spring-boot-saml su GitHub

Eseguendolo come applicazione Spring Boot (in esecuzione sull'SDK Application Server integrato), WebApp funziona correttamente.

Sfortunatamente, lo stesso processo AuthN non funziona affatto su Undertow / WildFly .

Secondo i registri, l'IdP esegue effettivamente il processo AuthN : le istruzioni della mia UserDetailsimplementazione personalizzata sono eseguite correttamente. Nonostante il flusso di esecuzione, Spring non imposta e mantiene i privilegi per l'utente corrente.

@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;
    }
}

Durante il debug, ho scoperto che il problema si basa sulla FilterChainProxyclasse. In fase di esecuzione, l'attributo FILTER_APPLIEDdi ServletRequestha un valore nullo , quindi Spring cancella il valore 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);
    }
}

Su VMware vFabric tc Sever e Tomcat , tutto funziona perfettamente. Hai idea di come risolvere questo problema?

— vdenotaris
fonte

Nella maggior parte dei casi, SecurityContextHolderdovrebbe essere cancellato dopo una richiesta. L'unico scopo di quel codice è nel caso in cui la catena di filtri sia applicata più di una volta durante la stessa richiesta (nel qual caso, solo la catena originale dovrebbe cancellare il contesto). Quindi non penso che sia un problema.

— Shaun the Sheep,

A proposito, questo comportamento invalida ogni volta il processo di accesso. Esiste un modo per risolverlo, ad esempio configurando correttamente il mio software dell'AS?

— vdenotaris,

Non sono sicuro di cosa intendi con questo. Quale comportamento e come si annulla l'accesso? Cancellare il contesto quando un thread termina la gestione di una richiesta è un comportamento normale: è essenziale impedire la perdita dei dati locali del thread in un pool di thread. A quel punto il contesto dovrebbe di solito essere memorizzato nella cache della sessione dell'utente. Quindi non dovrebbe invalidare un accesso.

— Shaun the Sheep,

Come descritto sopra, dopo SSO, Application Server cancella i dati della sessione e i dati di autenticazione. Ciò si verifica solo con Wildfly: lo stesso codice funziona bene con Tomcat.

— vdenotaris,

SecurityContextHolder.clearContext()non cancella i dati della sessione. Rimuove l' ThreadLocalarchiviazione del contesto prima di rilasciare nuovamente un thread nel pool di thread. Il mio punto è che questo dovrebbe accadere sempre alla fine di una richiesta, quindi quello che stai vedendo è normale e non è probabile che sia la causa del tuo problema.

— Shaun the Sheep,

Indagando sul problema ho notato che nella richiesta di autenticazione c'è qualche pasticcio con cookie e referenti.

Attualmente l'autenticazione wildfly funzionerà se si modifica il contesto dell'applicazione Web nel contesto radice:

 <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>

Dopo aver riavviato wildfly e aver cancellato i cookie, tutto dovrebbe funzionare come previsto

— nesteant
fonte

bella soluzione se sei famoso con WildFly e JBOSS puoi dare un'occhiata a questa domanda stackoverflow.com/questions/59006162/…

— ZINE Mahmoud,