Rest Anruf erfordert JSESSIONID (Spring Boot, Spring Sicherheit, OAuth2, Zuul)

Question

Ich habe zwei Spring-Boot-Prozesse. Ich habe Spring Security auf beiden aktiviert, und ich verwende Spring Security OAuth2 SSO-Setup. Ich verwende auch Eureka und Zuul, um Anrufe in Boot1 zu erlauben, um Dienste in Boot2 aufzurufen. UI verwendet Angular mit REST-Aufrufen in die Dienste, und das verwendete Token ist ein Json-Web-Token.

Dies scheint alles zu funktionieren, sicherlich in der Benutzeroberfläche. Alle Anforderungen verwenden den Autorisierungsheader (der die JWT enthält), und der Spring-Sicherheitsfilter in den Diensten analysiert die JWT erfolgreich und extrahiert den Sicherheitskontext daraus. Als Teil der Spring Web-Verarbeitung fügt es dem Cookie des Clients einen JSESSIONID-Wert hinzu.

Kürzlich hatte ich nur Frühlingssicherheit auf Boot1. Beim Aufrufen von Restdiensten in Boot1, die mit Zuul enden, um Anforderungen an Boot2 weiterzuleiten, war alles, was ich im Restclient benötigte, darin, den Authorization-Header mit der JWT einzuschließen, und alles war in Ordnung.

Allerdings habe ich Spring2d Boot2 (mithilfe der Annotation @EnableResourceServer) hinzugefügt und jetzt Ruheaufrufe schlagen fehl, es sei denn, ich habe sowohl die Autorisierung Header als auch eine Cookie-Header, die einen JSESSIONID-Wert enthält. Aufrufe schlagen nicht fehl, aber sie geben leere Werte zurück.

Ich habe die Anmeldung bei Spring Security aktiviert, und es überprüft alle korrekt in Boot1. Es geht in den gleichen ZuulFilter. Aber es gibt keine Aktivität auf Boot2.

Gibt es in Zuul etwas, das die Definition eines JSESSIONID-Werts erfordert, damit die Anforderung weitergeleitet wird? Oder ist dies in Boot2, wo es aufgrund der Einführung von Spring Security-Filtern einen JSESSIONID-Header-Wert erwartet?

--- --- Update

Ich habe durch boot1 trat. Von dem, was ich sehen kann, wirft der Code in OAuth2TokenRelayFilter eine Ausnahme. Insbesondere ruft die Methode getAccessToken restTemplate.getAccessToken(). GetValue (Zeile 90, Version 1.1.0-RELEASE) auf, die eine UserRedirectRequiredException auslöst.

Also, während der TokenRelayFilter ein Token hat, versucht es, es zu aktualisieren. Wenn eine Ausnahme empfangen wird, wird eine BadCredentialsException ausgelöst, anstatt die bereits definierten Werte zu verwenden.

--- Update 2 ---

Setzen Sie einen Haltepunkt in OAuth2RestOperationsConfiguration, Rest macht Anrufe ohne die JSESSIONID immer mit einem neuen DefaultOAuth2ClientContext endet erstellt werden, wie es versucht, Session-scoped Bohnen zu erstellen. Bei der JSESSIONID wird ein permanenter DefaultOAuth2ClientContext verwendet, der den Kontext hat.

Also, ist es möglich, beim Erstellen des DefaultOAuth2ClientContext zu sehen, ob die Anfrage das Token enthält und verwendet? Oder so ähnlich? Wir versuchen, zu staatenlosen Diensten überzugehen, und dies scheint eine Hürde dafür zu sein.

Answer 1

Es stellte sich heraus, dass dies ein Problem mit den Client-ID-Werten war, die von den verschiedenen Teilen des Systems verwendet wurden. Wenn OAuth2TokenRelayFilter aufgerufen wird, versucht es, das Token zu aktualisieren, wenn die für den Ressourcenserver (boot1) definierte Client-ID mit der übereinstimmt, die als Teil des Tokens definiert ist, das in dem mit der Anforderung bereitgestellten Token enthalten ist. In meinem Fall war das der Fall: Das Token wurde mit derselben Client-ID definiert.

Das ist wirklich nicht korrekt.Wenn ich meinen Rest-Client aktualisiere, um ein Token zu verwenden, aber beim Anfordern des Tokens eine andere Client-ID verwendet, wird die Anfrage wie erwartet korrekt weitergeleitet, ohne dass eine jsessionid benötigt wird. Das ist genau was ich will.

Ich vermute, dass dies am Ende durch falsche Verwendung der Client-ID-Werte durch die Komponenten meines Systems verursacht wurde.