2014-05-09 8 views
185

sto lavorando al fine di integrare Spring Security SAML Extension con Spring Boot.Primavera di sicurezza sul wildfly/Undertow: errore di esecuzione della catena dei filtri

ho sviluppato una completa applicazione di esempio, tutto il codice sorgente è pubblicato su GitHub:

Eseguendo il WebApp come applicazione di Primavera di avvio (attraverso Tool Set Primavera, da utilizzando un Application Server incorporato, funziona correttamente. Sfortunatamente, la procedura di autenticazione non funziona su Undertow/WildFly (e devo usarlo come AS di produzione).

Con la registrazione, posso vedere che l'IdP esegue il processo diAuthN e le istruzioni della mia implementazione personalizzata UserDetails eseguite correttamente. Nonostante ciò Spring non imposta 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("[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; 
    } 
} 

Per il debug, ho verificato che il problema inizia dalla classe FilterChainProxy. Quando eseguo la webapp su WildFly, posso vedere che l'attributo FILTER_APPLIED di ServletRequest è null, quindi Spring cancella il 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 che ciò non accada. C'è un modo per risolvere questo problema?

+2

Nella maggior parte delle situazioni, il 'SecurityContextHolder' dovrebbe essere cancellato dopo una richiesta. L'unico scopo di tale codice è nel caso in cui la catena di filtri venga 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. –

+2

BTW, questo comportamento invalida la procedura di accesso ogni volta. C'è un modo per risolverlo, ad esempio configurando correttamente il mio software dell'AS? – vdenotaris

+1

Non sei sicuro di cosa intendi con questo. Quale comportamento e in che modo annulla l'accesso? Cancellare il contesto quando un thread termina la gestione di una richiesta è un comportamento normale: è essenziale evitare che i dati locali del thread rimandino a un pool di thread. A quel punto il contesto dovrebbe solitamente essere memorizzato nella cache nella sessione dell'utente. Quindi non dovrebbe invalidare un login. –

risposta

5

Inchiesta sul problema Ho notato che c'è un pasticcio con i cookie e i riferimenti nella richiesta di autorizzazione.

autenticazione Attualmente wildfly funzionerà se si cambia contesto webapplication al contesto principale:

<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 di compensazione biscotti tutto dovrebbe funzionare come previsto

Problemi correlati