Spring Security auf Wildfly: Fehler während Ausführung der filter-Kette

Ich versuche zu integrieren Spring Security SAML-Erweiterung mit Spring Boot.

Über die Sache, die ich Tat entwickeln eine komplette Anwendung. Der Quellcode ist verfügbar auf GitHub:

Indem Sie es als Spring-Boot-Anwendung (laufen gegen die SDK built-in Application Server), die WebApp funktioniert einwandfrei.

Leider gleich AuthN-Prozess funktioniert überhaupt nicht auf Sog/WildFly.

Gemäß der Protokolle, die IdP-tatsächlich führt die AuthN - Prozess: die Anweisungen meiner benutzerdefinierten UserDetails Umsetzung sind korrekt ausgeführt. Trotz der Ausführung flow, Spring nicht einrichten und beibehalten der Berechtigungen für den aktuellen Benutzer.

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

Beim Debuggen habe ich herausgefunden, das problem beruht auf der FilterChainProxy Klasse. Zur Laufzeit das Attribut FILTER_APPLIED von ServletRequest hat eine null Wert, so Spring löscht die 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);
    }
}

Auf VMware vFabric tc Server und Tomcat, funktioniert alles völlig in Ordnung. Haben Sie eine Vorstellung über die Lösung dieses Problem?

  • In den meisten Situationen, die SecurityContextHolder sollte deaktiviert werden, nachdem eine Anfrage. Der einzige Zweck, dass code in der filter-Kette angewandt wird, mehr als einmal in derselben Anfrage (in dem Fall nur die original Kette sollte klar den Kontext). Also ich glaube nicht, dass das ein Problem.
  • BTW, dieses Verhalten Invaliden, den login-Prozess zu jeder Zeit. Gibt es eine Möglichkeit, es zu beheben, zum Beispiel durch die ordnungsgemäße Konfiguration meiner software, die ALS?
  • Nicht sicher, was Sie damit meinen. Was Verhalten, und wie kommt es zum erlöschen der login? Clearing-Rahmen, wenn ein thread beendet die Bearbeitung einer Anforderung normal-Verhalten ist es wichtig zu verhindern, dass undichte thread-lokale Daten zurück, um einen thread-pool. An diesem Punkt wird der Kontext sollte in der Regel zwischengespeichert werden in der Sitzung des Benutzers. Also sollte es nicht die Unwirksamkeit einer Anmeldung.
  • Wie oben beschrieben, nach der SSO, der Application Server löscht session-Daten und auth-Daten. Dies geschieht nur mit Wildfly: der gleiche code funktioniert mit Tomcat.
  • SecurityContextHolder.clearContext() nicht klar, die session-Daten. Es entfernt die ThreadLocal Lagerung der Kontext, vor dem veröffentlichen von einem thread zurück in den threadpool. Mein Punkt ist, dass dies sollte immer passieren, am Ende einer Anfrage, also was Sie sehen, ist normal und wahrscheinlich nicht die Ursache des Problems.
  • Sie haben einen benutzerdefinierten Sicherheits-Konfiguration? Wenn ja, wie fügen Sie Spring Security Filter?
  • Bitte überprüfen Sie die security.xml Datei , und dieser link , es könnte Ihnen helfen, raibledesigns.com/rd/entry/java_web_application_security_part1
  • Haben Sie befolgen Sie die servlet-API 3.1+ Integration Guide? docs.Frühling.io/spring-security/site/docs/current/Referenz/html/...
  • Verstehe ich richtig, dass lauffähige code von github wird ein Problem reproduzieren?

InformationsquelleAutor vdenotaris | 2014-05-09
Schreibe einen Kommentar