Wenn eine Spring-Anwendung eine 403- oder 401-Antwort zurückgibt, bevor ein Haltepunkt innerhalb eines Controllers oder Dienstes erreicht wird, liegt das Problem möglicherweise nicht in der Logik, die der Entwickler untersuchen möchte, sondern in der Autorisierungsschicht, die der Anfrageausführung vorausgeht. IntelliJ IDEA bietet eine Möglichkeit, die tatsächlichen Schutzregeln in der laufenden Anwendung zu prüfen und der Anfrage während einer Debugging-Sitzung vorübergehend eine Identität und Berechtigungen zu gewähren, ohne SecurityConfig zu ändern oder die Anwendung neu zu starten.
Die Funktion ist Bestandteil des Spring-Debugger-Plugins in IntelliJ IDEA Ultimate und seit Version 2026.2 verfügbar. Security-Inlays werden während der Ausführung des Debuggers standardmäßig angezeigt, unabhängig davon, ob die Anwendung lokal oder auf einer entfernten JVM läuft.
Beginnen Sie damit, herauszufinden, was der Pfad tatsächlich verlangt
Die Oberfläche im Editor oder in der HTTP-Datei zeigt die für den Endpunkt geltenden rollen- und berechtigungsbasierten Anforderungen an, einschließlich der auf hasRole und hasAuthority basierenden Regeln. IntelliJ IDEA verlässt sich dabei nicht nur auf das Auslesen der Konfigurationsdateien, sondern untersucht die tatsächliche SecurityFilterChain innerhalb der JVM, nachdem der Spring-Kontext initialisiert wurde. Das ist wichtig, wenn mehrere SecurityFilterChain, die Reihenfolge der Matcher, aktive Profile oder die bedingte Registrierung von Konfigurationen das endgültige Ergebnis beeinflussen.
Wenn eine bestimmte Regel nicht in eine Rollenliste umgewandelt werden kann, wie es bei einigen benutzerdefinierten AuthorizationManager-Implementierungen der Fall ist, wird die Regel als unbekannter Zustand angezeigt, zusammen mit einem Link zum relevanten Code der Sicherheitskonfiguration. In diesem Fall steht das automatische Öffnen auf Grundlage der Rollenliste nicht zur Verfügung, und ein Blick in die SecurityConfig bleibt erforderlich.
Den Pfad während der Debugging-Sitzung vorübergehend öffnen
Die Aktion „Unlock“ bietet zwei Optionen. Die erste behandelt die Anfrage als authentifiziert mit der für den Pfad erforderlichen Rollengruppe. Sie eignet sich, wenn der Entwickler die Logik des Controllers oder Dienstes hinter einem geschützten Pfad testen möchte. Die zweite ermöglicht die Angabe eines Benutzernamens und einer benutzerdefinierten Berechtigungsliste, etwa admin mit ROLE_ADMIN und ROLE_MANAGER, um das Verhalten der Anwendung unter einer bestimmten Berechtigungsgruppe zu testen.
Bei der Ausführung der Aktion erstellt der Debugger ein TestingAuthenticationToken-Objekt innerhalb des SecurityContext der laufenden Anwendung. Prüfungen mit hasRole und hasAuthority sowie SecurityContextHolder.getContext().getAuthentication() und Parameter vom Typ Principal oder Authentication sehen die vom Entwickler festgelegte Identität und Berechtigungen. Die Aktion ändert weder den Anwendungscode noch die Konfigurationsdateien, und die geöffneten Pfade verschwinden beim Neustart der Anwendung, einschließlich eines prozessinternen Neustarts über Spring Boot DevTools, oder wenn der Pfad manuell wieder gesperrt wird.
Die Auswirkung beschränkt sich nicht auf die von IntelliJ IDEA gesendete Anfrage. Das Öffnen eines GET-Pfads wirkt sich auf jeden Client aus, der dieselbe URI und dieselbe HTTP-Methode verwendet, etwa curl, Postman oder einen Browser. Wenn ein Pfadmuster in einer Controller-Definition geöffnet wird, kann dies alle Werte einschließen, die auf das Muster passen. Deshalb sollte der Pfad nach Abschluss der Arbeit wieder gesperrt oder die Debugging-Sitzung beendet werden, insbesondere wenn die Anwendung über das Netzwerk erreichbar ist.
Was wird durch „Unlock“ nicht umgangen?
Die Aktion deaktiviert Spring Security nicht vollständig und umgeht auch nicht den CSRF-Schutz. Wenn eine POST-, PUT- oder DELETE-Anfrage ein gültiges CSRF-Token benötigt, kann der CsrfFilter sie weiterhin ablehnen. Außerdem ist der Geltungsbereich auf die Autorisierung von Endpunkten über den AuthorizationFilter innerhalb des Servlet-Stacks beschränkt; Spring WebFlux, das AuthorizationWebFilter verwendet, wird nicht unterstützt.
Es gibt keine direkte Oberfläche zum Anzeigen oder Öffnen von Schutzanforderungen auf Methodenebene wie @PreAuthorize, @PostAuthorize und @Secured. Die in den SecurityContext injizierten Berechtigungen können jedoch später von der Methodenschutz-Interception gelesen werden. Daher kann ein durch @PreAuthorize geschützter Dienstaufruf erfolgreich sein, wenn die gewährten Berechtigungen seine Bedingung erfüllen. Das bedeutet nicht, dass IntelliJ IDEA den Methodenschutz selbst geöffnet hat, sondern dass die Prüfung denselben künstlichen Authentifizierungskontext gelesen hat.
Einschränkungen der Identität und Integration mit Testwerkzeugen
Die vom Debugger erstellte Identität ist ein textueller Benutzername innerhalb eines TestingAuthenticationToken und weder das UserDetails-Objekt der Anwendung noch ein benutzerdefinierter Typ eines Benutzerobjekts. Daher kann ein Parameter mit @AuthenticationPrincipal den Wert null zurückgeben. Dies ist ein bekanntes Problem mit der Nummer IDEA-389767, das zum Zeitpunkt der Veröffentlichung des Artikels die Version 2026.2 betraf.
Principal oder Authentication können als Parametertyp verwendet werden. Die Abhängigkeit von einem konkreten Typ wie JwtAuthenticationToken kann jedoch zu einer IllegalStateException führen, da das injizierte Objekt nicht diesem Typ angehört. Ebenso können sich die Ergebnisse unterscheiden oder Teile fehlschlagen, die auf Claims, Credentials, eine sitzungsgebundene Identität oder eine bestimmte Art von Authentifizierungstoken angewiesen sind.
Das Öffnen funktioniert mit Anfragen aus der integrierten .http-Datei sowie mit curl, Postman und Test-Frameworks, sofern die laufende Anwendung dieselbe ist, in der der Pfad geöffnet wurde. Für automatisierte Workflows oder solche, die auf Agenten mit künstlicher Intelligenz basieren, gibt es derzeit keinen programmgesteuerten Schlüssel zur Ausführung der Aktion. JetBrains plant, in Version 2026.3 ein MCP-Tool und eine damit verbundene Fähigkeit hinzuzufügen. Die aktuelle Version erfordert jedoch zunächst einen manuellen Klick innerhalb der IDE.
Warum ist diese Vorgehensweise wichtig?
Der praktische Wert liegt hier nicht in der Deaktivierung des Schutzes, sondern darin, die Autorisierungsschicht von der Logik zu isolieren, die der Entwickler testen möchte, ohne vorübergehende Änderungen in Konfigurationsdateien zu hinterlassen, die vergessen und in eine andere Umgebung übernommen werden könnten. Gleichzeitig stellt das Öffnen eine vorübergehende Sicherheitsänderung im laufenden Prozess dar und keine lokale Simulation, die auf eine von der IDE gesendete Anfrage beschränkt ist. Daher sollte es als gezielt begrenztes Debugging-Werkzeug betrachtet werden, nicht als Ersatz für echte Authentifizierungstests. Vor seiner Verwendung sollten der Pfad, die Methode und die betroffenen Clients überprüft werden.
Außerdem ist zu beachten, dass die Funktion beim Öffnen eines Pfads in einer entfernten Anwendung keine Nachricht in den Protokollen erfasst und keinen Indikator über Actuator bereitstellt. Laut Artikel kann der Status nur über die Oberfläche in der mit der Anwendung verbundenen IDE überprüft werden. Security-Inlays können deaktiviert werden, indem die Einstellung spring.debugger.security.enabled in der Registry von IntelliJ IDEA geändert wird, wenn sie nicht benötigt werden.