Spring Security en Wildfly: error al ejecutar la cadena de filtros

194

Estoy tratando de integrar Spring Security SAML Extension con Spring Boot .

Sobre el asunto, desarrollé una aplicación de muestra completa. Su código fuente está disponible en GitHub:

Spring-boot-saml -integration en GitHub

Al ejecutarlo como la aplicación Spring Boot (que se ejecuta en el servidor de aplicaciones integrado del SDK), la aplicación web funciona bien.

Desafortunadamente, el mismo proceso AuthN no funciona en absoluto en Undertow / WildFly .

Según los registros, el IdP realmente realiza el proceso AuthN : las instrucciones de mi UserDetailsimplementación personalizada se ejecutan correctamente. A pesar del flujo de ejecución, Spring no configura y persiste los privilegios para el usuario actual.

@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 la depuración, descubrí que el problema depende de la FilterChainProxyclase. En tiempo de ejecución, el atributo FILTER_APPLIEDde ServletRequesttiene un valor nulo , por lo que Spring borra el 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);
    }
}

En VMware vFabric tc Sever y Tomcat , todo funciona perfectamente. ¿Tienes alguna idea sobre cómo resolver este problema?

— vdenotaris
fuente

En la mayoría de las situaciones, se SecurityContextHolderdebe borrar después de una solicitud. El único propósito de ese código es en caso de que la cadena de filtro se aplique más de una vez durante la misma solicitud (en cuyo caso, solo la cadena original debe borrar el contexto). Entonces no creo que sea un problema.

— Shaun the Sheep

Por cierto, este comportamiento invalida el proceso de inicio de sesión cada vez. ¿Hay alguna forma de solucionarlo, por ejemplo, configurando correctamente mi software del AS?

— vdenotaris

No estoy seguro de lo que quieres decir con esto. ¿Qué comportamiento y cómo invalida el inicio de sesión? Borrar el contexto cuando un subproceso termina de manejar una solicitud es un comportamiento normal: es esencial para evitar la pérdida de datos locales del subproceso a un grupo de subprocesos. En ese punto, el contexto generalmente debe almacenarse en caché en la sesión del usuario. Por lo tanto, no debería invalidar un inicio de sesión.

— Shaun the Sheep

Como se describió anteriormente, después del SSO, el servidor de aplicaciones borra los datos de la sesión y los datos de autenticación. Esto ocurre solo con Wildfly: el mismo código funciona bien con Tomcat.

— vdenotaris

SecurityContextHolder.clearContext()no borra los datos de la sesión. Elimina el ThreadLocalalmacenamiento del contexto antes de volver a liberar un subproceso en el grupo de subprocesos. Mi punto es que esto siempre debe suceder al final de una solicitud, por lo que lo que está viendo es normal y no es probable que sea la causa de su problema.

— Shaun the Sheep

Investigando el problema, he notado que hay algún problema con las cookies y los referentes en la solicitud de autenticación.

Actualmente, la autenticación wildfly funcionará si cambia el contexto de la aplicación web al contexto raíz:

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

Después de reiniciar wildfly y borrar las cookies, todas deberían funcionar como se esperaba

— inquilino
fuente

buena solución si eres famoso con WildFly y JBOSS, ¿puedes echar un vistazo a esa pregunta stackoverflow.com/questions/59006162/…

— ZINE Mahmoud