Spring Security SAML-Assertionsablauf mit Ablauf der Anwendungssitzung

Question

Ich bin verwirrt mit dem Ablauf der SAML-Assertion gegen den Ablauf der Anwendungssitzung.

In einfachen Worten, wenn eine Anwendung in einem Container bereitgestellt wird, wird eine Sitzung erstellt. Diese Sitzung Ablauf kann mit dem unten stehenden Eintrag in web.xml

<session-config> 
    <session-timeout>60</session-timeout> 
</session-config> 

Umzug auf, gesteuert werden, wenn ich Spring Security mit SAML-Erweiterung habe, offensichtlich das gleiche Session-Konzept gilt. (Ich verwende die Anwendung in WildFly 8.2, wenn das wichtig ist)

Weiter, wenn die Anwendungssitzung abläuft, scheint das Abmeldeverhalten zu Local Logout-Konzept entsprechen.

So weit so gut. Nun sagen wir, dass die SAML-Assertion für 2 Stunden gut ist und der Benutzer seit 2 Stunden aktiv arbeitet. Was soll dann mit der anschließenden Anfrage geschehen? Sollte es sich erneut beim IDP anmelden? Aber wäre das nicht unangenehm für den Benutzer? Wenn die Anwendung nach 2 Stunden Ablauf der Geltendmachung erneut an IDP weitergeleitet wird, um sich erneut anzumelden, Wie sollten AJAX-Anfragen behandelt werden? Diese

ist in Bezug auf the question here

Answer 1

Frühling SAML gibt eine ExpiringUsernameAuthenticationToken für authentifizierte Benutzer. Das Token beginnt in seiner Methode mit false zurück, sobald die SAML-Assertion, die zur Authentifizierung des Benutzers verwendet wurde, seine sessionNotOnOrAfter Zeit erreicht.

Dieses Verhalten kann durch zwingende SAMLAuthenticationProvider und Änderungsverfahren getExpirationDate(credential), die Zeit zurückgibt, deaktiviert werden, wenn die Assertion abläuft oder null falls es nie. Die Anwendung verlässt sich dann vollständig auf den Ablauf der Sitzung, der im Container konfiguriert wurde.

Sobald die ExpiringUsernameAuthenticationToken abläuft, übergibt Spring Security das aktuelle Token an die (konfiguriert in securityContext.xml unter <security:authentication-manager>).

Sie können beeinflussen, was als nächstes passiert, indem Sie Ihre eigenen AuthenticationProvider in der Lage, die ExpiringUsernameAuthenticationToken zu behandeln. Andernfalls schlägt das System mit ProviderNotFoundException oder einem anderen AuthenticationException wie BadCredentialsException fehl (falls Sie die Authentifizierung mit Benutzername/Passwort gleichzeitig verwenden).

Die Ausnahme wird anschließend von ExceptionTranslationFilter behandelt, die den neuen Authentifizierungsvorgang durch Aufrufen der konfigurierten Authentifizierung EntryPoint - z. SAMLEntryPoint, die entweder die Authentifizierung mit dem Standard-IDP startet oder die IDP-Auswahlseite anzeigt. Der Prozess führt im Wesentlichen auch eine lokale Abmeldung durch, wie Sie sagen.

Das System verhält sich standardmäßig für alle HTTP-Aufrufe gleich - AJAX oder nicht. Sie können ein unterschiedliches Verhalten definieren, indem Sie Ihre API und normale URLs in separate <security:http> Elemente aufteilen und unterschiedliche EntryPoints (Schnittstelle AuthenticationEntryPoint) für jedes Element verwenden. Zum Beispiel könnte Http403ForbiddenEntryPoint für Ihre AJAX-Anrufe geeignet sein.