2016-03-07 8 views
5

meinen Kontext Anbieter Befestigt für SAMLContextProviderLB beanSpring Security SAML, leitet geht anstelle von HTTPS auf HTTP bei Verwendung von SAMLContextProviderLB zu HTTPs gesetzt Schema

**<property name="scheme" value="https"/>** 
     <property name="serverName" value="${sp.hostname}"/> 
     <property name="serverPort" value="#{'${sp.ssl.port}'=='' ? 443 : '${sp.ssl.port}'}"/> 
     <property name="includeServerPortInRequestURL" value="#{'${sp.ssl.port}'=='443' ? false : true }"/> 
     <property name="contextPath" value="/${sp.context.root}"/> 

ich hinter einer Reverse-Proxy bin so die SSL-Termination ich Offloading . Der Back-End-Server selbst überwacht Nicht-SSL, aber das Web-Tier beendet das SSL für uns und leitet es an den Nicht-SSL-Port weiter. Ich habe SAMLContextProviderLB mit den oben genannten Eigenschaften eingerichtet, so dass, auch wenn das Back-End https ist, der beabsichtigte Empfänger für das saml-Token als HTTPS-Zielgruppe zugeordnet wird. Was ich in den Logs unten sehe, ist jedoch, wenn ich zu einer geschützten Ressource gehe, Müll im Browser. Wenn ich es im Browser zu https ändere, funktioniert es wie gewünscht. Die folgenden Protokolle zeigen, dass der von DefaultSavedRequest url zurückgegebene Wert HTTP ist, wenn es HTTPs sein sollte.

2016-03-07 18: 24: 11.907 INFO org.springframework.security.saml.log.SAMLDefaultLogger.log: 127 - AuthNResponse; SUCCESS; 10.4.203.88; https://myserver:89/fct;https://www.myADFS.com/adfs/services/trust;[email protected] ;;

2016-03-07 18: 24: 11.909 DEBUG org.springframework.security.saml.SAMLprocessingFilter.successfulAuthentication: 317 - Authentifizierung erfolgreich. Aktualisieren von SecurityContextHolder mit folgendem Inhalt: org.springf[email protected]830e9237: Principal: [email protected]; Anmeldeinformationen: [GESCHÜTZT]; Authentifiziert: wahr; Details: null; Nicht gewährt keine Behörden

2016-03-07 18: 24: 11.910 DEBUG org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler.onAuthenticationSuccess: 79 - Umleiten zu DefaultSavedRequest URL: http : // myserver: 89/FCT/Seite

2016-03-07 18: 24: 11.911 DEBUG org.springframework.security.web.DefaultRedirectStrategy.sendRedirect: 36 - Umleiten zu 'http://myserver:89/fct/page'

2016-03-07 18: 24: 11.911 DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository.saveCon text: 292 - SecurityContext gespeichert in HttpSession: '[email protected]0e9237: Authentifizierung: org.springf[email protected]830e9237: Principal: [email protected]; Anmeldeinformationen: [GESCHÜTZT]; Authentifiziert: wahr; Details: null; Nicht alle Behörden gewährt

2016.03.07 18: 24: 11.912 DEBUG org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter: 97 - SecurityContextHolder jetzt gelöscht, wie Anforderungsverarbeitung abgeschlossen

Irgendwelche Ideen Wie erzwinge ich dies zu HTTPS? Danke im Voraus.

Antwort

3

Diese Frage ist alt, aber wenn ich es jemand anderes finden könnte, werde ich eine Antwort posten.

Entweder Ihr Load Balancer oder Ihr Reverse Proxy (Apache httpd oder nginx) muss etwas mehr Arbeit für Sie erledigen. Spring (oder Spring Boot) und die eingebetteten Tomcat (oder Jetty) denken, dass sie einen HTTP-Server ausführen. Was es macht. Wenn der Proxy einige Header-Variablen übergibt, beginnt Tomcat zu denken, dass es https ausgeführt wird.Hier

ist, was Apache als Beispiel benötigt:

ProxyPreserveHost On 
RequestHeader add X-Forwarded-Proto https 
ProxyPass/http://127.0.0.1:8080/ 
ProxyPassReverse/http://127.0.0.1:8080/ 

ProxyPass und ProxyPassReverse sind, was Sie wahrscheinlich bereits haben. Aber die ProxyPreserveHost und die X-Forwarded-Proto zählen wirklich.

Überprüfen Sie diesen Abschnitt der Spring Boot Docs. Wenn X-Forwarded-For oder X-Forwarded-Proto eingestellt sind, müssen Sie dies Ihrer application.properties Datei hinzuzufügen:

server.use-forward-headers=true 

Sie werden auch in diesem Dokument sehen, dass Sie diese Eigenschaften für Tomcat spezifische Konfiguration hinzufügen:

server.tomcat.remote-ip-header=x-your-remote-ip-header 
server.tomcat.protocol-header=x-your-protocol-header 

Tun Sie das alles zusätzlich zu was Sie oben haben und es wird zu arbeiten beginnen. Was Sie oben haben, allein reicht nicht aus, um Tomcat zu zwingen, Anfragen mit https zu starten.

Da meine Firma einen hardwarebasierten Load Balancer (der von Rackspace verwaltet wird) hatte, war es schwierig, diese Änderungen zu konfigurieren. Also führen wir eine SSL-Terminierung in der Firewall/dem Load-Balancer durch, leiten die Anfragen dann an Port 80 an Apache weiter und Apache leitet sie über Port 8080 an Java weiter. Ja, es ist ein Durcheinander. Aber es hat all diesen Unsinn funktioniert.