Spring Security - Sicherheit keine, Filter keine, ZugriffserlaubnisAlle
1. Überblick
Spring Security bietet verschiedene Mechanismen, um ein Anforderungsmuster als ungesichert zu konfigurieren oder den gesamten Zugriff zuzulassen. Abhängig von jedem dieser Mechanismen kann dies entweder bedeuten, dass die Sicherheitsfilterkette auf diesem Pfad überhaupt nicht ausgeführt wird, oder dass die Filterkette ausgeführt wird und der Zugriff zugelassen wird.
Weitere Lektüre:
Spring Security - Rollen und Privilegien
So ordnen Sie Rollen und Berechtigungen für eine Spring Security-Anwendung zu: das Setup, die Authentifizierung und den Registrierungsprozess.
Frühjahrssicherheit für eine REST-API
So sichern Sie eine REST-API mit Spring Security: XML-Konfiguration, web.xml, HTTP-Statuscodes für die Authentifizierung usw.
Spring Security Expressions - hasRole Beispiel
Einführung in den Sicherheitsausdruck von hasRole Spring: Richten Sie die Webautorisierung nach URL und auf der Seite sowie die Methodensicherheit mit @PreAuthorize ein.
2. access=”permitAll”
Wenn Sie ein<intercept-url>-Element mitaccess=”permitAll” einrichten, wird die Autorisierung so konfiguriert, dass alle Anforderungenallowed auf diesem bestimmten Pfad sind:
Oder über die Java-Konfiguration:
http.authorizeRequests().antMatchers("/login*").permitAll();Dies wird inwithout disabling the security filters erreicht - diese werden weiterhin ausgeführt, sodass alle Spring Security-bezogenen Funktionen weiterhin verfügbar sind.
3. filters=”none”
Dies ist eine Pre-Spring 3.1-Funktion, diedeprecated and replaced in Spring 3.1. betrug
Das Attributfilters deaktiviert die Spring Security-Filterkette vollständig für diesen bestimmten Anforderungspfad:
Dies kann zu Problemen führen, wenn für die Verarbeitung der Anforderung einige Funktionen von Spring Security erforderlich sind.
Da es sich um eine veraltete Funktion handelt, für die Spring-Versionen älter als 3.0 sind, führt die Verwendung mit Spring 3.1 beim Start zu einer Laufzeitausnahme:
SEVERE: Context initialization failed
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: The use of "filters='none'" is no longer supported.
Please define a separate element for the pattern you want to exclude
and use the attribute "security='none'".
Offending resource: class path resource [webSecurityConfig.xml]
at o.s.b.f.p.FailFastProblemReporter.error(FailFastProblemReporter.java:68) 4. security=”none”
Wie wir in der obigen Fehlermeldung gesehen haben, ersetzt Spring 3.1filters=”none” durch einen neuen Ausdruck -security=”none”.
Der Bereich hat sich ebenfalls geändert - dies wird auf der Elementebene von<intercept-url>nicht mehr angegeben. Stattdessen können in Spring 3.1multiple <http> elements definiert werden - jede mit ihrer eigenen Konfiguration der Sicherheitsfilterkette. Daher gehört das neue Sicherheitsattribut jetzt auf der Elementebene von<http>.
In der Praxis wird dies so aussehen:
Oder mit Java-Konfiguration:
web.ignoring().antMatchers("/resources/**");Anstelle der alten:
Ähnlich wie beifilters=”none” wird auch hier die Sicherheitsfilterkette für diesen Anforderungspfad vollständig deaktiviert. Wenn die Anforderung in der Anwendung verarbeitet wird, sind die Spring Security-Funktionen nicht verfügbar.
Dies ist kein Problem für die obigen Beispiele, die sich hauptsächlich mitserving static resources befassen - wo keine tatsächliche Verarbeitung stattfindet. Wenn die Anforderung jedoch auf irgendeine Weise programmgesteuert behandelt wird, sind Sicherheitsfunktionen wierequires-channel, der Zugriff auf den aktuellen Benutzer oder das Aufrufen gesicherter Methoden nicht verfügbar.
Aus dem gleichen Grund macht es keinen Sinn, zusätzliche Attribute für ein<http>-Element anzugeben, das bereits mitsecurity=”none” konfiguriert wurde, da dieser Anforderungspfad ungesichert ist und die Attribute einfach ignoriert werden.
Alternativ kannaccess='IS_AUTHENTICATED_ANONYMOUSLY' verwendet werden, um anonymen Zugriff zu ermöglichen.
5. Vorsichtsmaßnahmen fürsecurity=”none”
Beachten Sie bei der Verwendung mehrerer<http>-Elemente, von denen einige mitsecurity=”none” konfiguriert sind, dass die Reihenfolge, in der diese Elemente definiert sind, wichtig ist. Wir möchten zuerst die spezifischen<http>-Pfade haben und ganz am Ende dem universellen Muster folgen.
Beachten Sie auch, dass, wenn ein<http>-Elementdoesn’t specify a pattern ist, dies standardmäßig dem universellen Übereinstimmungsmuster zugeordnet ist - “/*” – so again, this element needs to be last. If the order of the elements is not correct, the *creation of the security filter chain will fail:
Caused by: java.lang.IllegalArgumentException: A universal match pattern ('/**')
is defined before other patterns in the filter chain, causing them to be ignored.
Please check the ordering in your namespace or FilterChainProxy bean configuration
at o.s.s.c.h.DefaultFilterChainValidator.checkPathOrder(DefaultFilterChainValidator.java:49)
at o.s.s.c.h.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:39) 6. Fazit
In diesem Artikel werden die Optionen zum Ermöglichen des Zugriffs auf einen Pfad mit Spring Security erläutert, wobei die Unterschiede zwischenfilters=”none”, security=”none” and access=”permitAll” im Mittelpunkt stehen.
Wie üblich sind die Beispiele inover on GitHub verfügbar.