Shinyproxy: Zeitüberschreitung bei SAML-Authentifizierung (?) Fehler

Erstellt am 15. Feb. 2021 · 6Kommentare · Quelle: openanalytics/shinyproxy

Hallo wieder! Während wir die Entwicklung unserer App mit SAML vorantreiben, haben wir ein Problem mit der Authentifizierung festgestellt, das nur aufzutreten scheint, wenn ein Tab für einige Zeit geöffnet bleibt (ich habe nicht die genaue Zeitspanne ermittelt, die das Problem verursacht). und ein Benutzer aktualisiert dann seine Registerkarte (nicht sicher, ob ein neues Fenster es an dieser Stelle auch auslöst). Es scheint, dass ShinyProxy nach dieser Zeit der Inaktivität versucht, sich erneut zu authentifizieren und aus irgendeinem Grund fehlschlägt. Die einzige Lösung, die ich gefunden habe, besteht darin, die Site-Daten im Browser für unseren IdP (auth.company.com) zu löschen. Sobald dies erledigt ist, funktionieren die Dinge wie erwartet.

Wenn dies geschieht, versucht ShinyProxy viele Male hintereinander, sich zu authentifizieren (ich kann viele SAML-Umleitungsrückrufe in der URL-Leiste sehen), schlägt jedoch schließlich fehl und verschiebt mich auf http://my.company.com/app/saml /SSO mit folgendem Fehler:

In den Serverlogs sehe ich folgendes:

shinyproxy-server_1  | 2021-02-15 04:00:11.531  INFO 1 --- [  XNIO-1 task-4] o.s.security.saml.log.SAMLDefaultLogger  : AuthNRequest;SUCCESS;XXX.XX.XX.XXX;https://my.company.com/app;http://auth.company.com/adfs/services/trust;;;
shinyproxy-server_1  | 2021-02-15 04:00:11.608  INFO 1 --- [  XNIO-1 task-4] colMessageXMLSignatureSecurityPolicyRule : Validation of protocol message signature succeeded, message type: {urn:oasis:names:tc:SAML:2.0:protocol}Response
shinyproxy-server_1  | 2021-02-15 04:00:11.609  INFO 1 --- [  XNIO-1 task-4] o.s.security.saml.log.SAMLDefaultLogger  : AuthNResponse;FAILURE;XXX.XX.XX.XXX;https://my.company.com/app;http://auth.company.com/adfs/services/trust;;;org.springframework.security.saml.SAMLStatusException: Response has invalid status code urn:oasis:names:tc:SAML:2.0:status:Responder, status message is null

Etwas Seltsames ist, dass es so aussieht, als ob der erste Authentifizierungsversuch erfolgreich war, aber ShinyProxy es aus irgendeinem Grund nicht mag und es erneut versucht.

Vollständige Fehlerverfolgung:

~~~glänzendproxy-server_1 |~~
~~unter org.springframework.security.saml.SAMLAuthenticationProvider.authenticate(SAMLAuthenticationProvider.java:88)glänzendproxy-server_1 |~~
~~unter org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:219)glänzendproxy-server_1 |~~
~~at sun.reflect.GeneratedMethodAccessor63.invoke(Unbekannte Quelle)glänzendproxy-server_1 |~~
~~at java.lang.reflect.Method.invoke(Method.java:498)glänzendproxy-server_1 |~~
~~unter org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:205)glänzendproxy-server_1 |~~
~~unter org.springframework.security.saml.SAMLProcessingFilter.attemptAuthentication(SAMLProcessingFilter.java:92)glänzendproxy-server_1 |~~
~~bei org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)glänzendproxy-server_1 |~~
~~bei org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:186)glänzendproxy-server_1 |~~
~~bei org.springframework.security.web.authentication.~~
~~bei org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)glänzendproxy-server_1 |~~
~~at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:200)glänzendproxy-server_1 |~~
~~bei org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:116)glänzendproxy-server_1 |~~
~~unter org.springframework.security.web.csrf.CsrfFilter.doFilterInternal(CsrfFilter.java:117)glänzendproxy-server_1 |~~
~~bei org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)glänzendproxy-server_1 |~~
~~bei org.springframework.security.web.header.HeaderWriterFilter.doFilterInternal(HeaderWriterFilter.java:77)glänzendproxy-server_1 |~~
~~bei org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)glänzendproxy-server_1 |~~
~~bei org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)glänzendproxy-server_1 |~~
~~bei org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)glänzendproxy-server_1 |~~
~~at org.springframework.security.saml.metadata.MetadataGeneratorFilter.doFilter(MetadataGeneratorFilter.java:87)glänzendproxy-server_1 |~~
~~bei org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:215)glänzendproxy-server_1 |~~
~~bei org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:358)glänzendproxy-server_1 |~~
~~unter io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)glänzendproxy-server_1 |~~
~~bei org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100)glänzendproxy-server_1 |~~
~~unter io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)glänzendproxy-server_1 |~~
~~at org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.doFilterInternal(WebMvcMetricsFilter.java:93)glänzendproxy-server_1 |~~
~~unter io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)glänzendproxy-server_1 |~~
~~bei org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201)glänzendproxy-server_1 |~~
~~unter io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)glänzendproxy-server_1 |~~
~~bei io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)glänzendproxy-server_1 |~~
~~bei io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)glänzendproxy-server_1 |~~
~~bei io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91)glänzendproxy-server_1 |~~
~~bei io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)glänzendproxy-server_1 |~~
~~at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)glänzendproxy-server_1 |~~
~~at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)glänzendproxy-server_1 |~~
~~at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)glänzendproxy-server_1 |~~
~~at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)glänzendproxy-server_1 |~~
~~bei io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)glänzendproxy-server_1 |~~
~~bei io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)glänzendproxy-server_1 |~~
~~at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)glänzendproxy-server_1 |~~
~~at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)glänzendproxy-server_1 |~~
~~at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)glänzendproxy-server_1 |~~
~~at io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)glänzendproxy-server_1 |~~
~~at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)glänzendproxy-server_1 |~~
~~at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1558)glänzendproxy-server_1 |~~
~~bei java.lang.Thread.run(Thread.java:748)~~~

Die einfache Lösung wäre, auf die Schaltfläche "Abmelden" zu klicken, diese Schaltfläche wird jedoch nicht auf dem SAML-Fehlerbildschirm angezeigt. Es ist schwer zu debuggen, weil ich es nicht auf Anfrage ausführen kann. Laut meiner IdP-Supportperson stellt ADFS zu Beginn dieses Prozesses tatsächlich ein gültiges Token aus, daher scheint es ein lokales Problem zu sein, wie ShinyProxy mit dem empfangenen Token umgeht. Ich vermute, da der Browser-Tab nie geschlossen wurde, ist das Anmelde-Cookie möglicherweise abgelaufen und wird nicht korrekt erneuert, aber ich habe keine Ahnung, wovon ich spreche, also nehmen Sie das mit Vorsicht.

Ich werde mit hoffentlich mehr nützlichen Informationen zurückkommen, wenn der Fehler wieder auftritt, aber ich war neugierig, ob das jemand gesehen hat und eine Idee hat, wie man es beheben kann?

question

Quelle

jat255

Alle 6 Kommentare

Ich habe das folgende Problem gefunden , das auf ähnliche Fehlermeldungen hinweist, die auf eine Nichtübereinstimmung zwischen SHA-1- und SHA-256-Signaturalgorithmen hinweisen, aber wenn dies bei unserer Installation der Fall wäre, bin ich mir nicht sicher, warum es die meiste Zeit funktionieren würde. aber dann nach einer langen Zeit der Inaktivität zeitweise fehlschlagen, also denke ich nicht, dass dies mein Problem ist.

jat255 am 15. Feb. 2021

Als Nachfolge habe ich den SAML-Teil der App auf DEBUG Level-Logging gesetzt und folgendes von einem dieser Timeout-Ereignisse gesehen:

shinyproxy-server_1  | 2021-02-15 21:03:14.050 DEBUG 1 --- [  XNIO-1 task-2] o.s.s.s.context.SAMLContextProviderImpl  : No IDP specified, using default http://auth.company.com/adfs/services/trust
shinyproxy-server_1  | 2021-02-15 21:03:14.050 DEBUG 1 --- [  XNIO-1 task-2] o.s.security.saml.util.SAMLUtil          : Index for AssertionConsumerService not specified, returning default
shinyproxy-server_1  | 2021-02-15 21:03:14.051 DEBUG 1 --- [  XNIO-1 task-2] o.s.security.saml.SAMLEntryPoint         : Processing SSO using WebSSO profile
shinyproxy-server_1  | 2021-02-15 21:03:14.051 DEBUG 1 --- [  XNIO-1 task-2] o.s.s.saml.websso.WebSSOProfileImpl      : Using default consumer service with binding urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
shinyproxy-server_1  | 2021-02-15 21:03:14.052 DEBUG 1 --- [  XNIO-1 task-2] o.s.s.saml.storage.HttpSessionStorage    : Storing message a17g5ahbxxxxxxxxxxx454jj to session hxxxxxxJ_E8xxxxxxxxHP_TwIxxxxxxxH
shinyproxy-server_1  | 2021-02-15 21:03:14.053  INFO 1 --- [  XNIO-1 task-2] o.s.security.saml.log.SAMLDefaultLogger  : AuthNRequest;SUCCESS;XXX.XX.XXX.XX;https://my.company.com/app;http://auth.company.com/adfs/services/trust;;;
shinyproxy-server_1  | 2021-02-15 21:03:14.805 DEBUG 1 --- [  XNIO-1 task-2] o.s.security.saml.SAMLProcessingFilter   : Request is to process authentication
shinyproxy-server_1  | 2021-02-15 21:03:14.806 DEBUG 1 --- [  XNIO-1 task-2] o.s.security.saml.SAMLProcessingFilter   : Attempting SAML2 authentication using profile urn:oasis:names:tc:SAML:2.0:profiles:SSO:browser
shinyproxy-server_1  | 2021-02-15 21:03:14.811 DEBUG 1 --- [  XNIO-1 task-2] o.s.s.saml.processor.SAMLProcessorImpl   : Retrieving message using binding urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
shinyproxy-server_1  | 2021-02-15 21:03:14.816  INFO 1 --- [  XNIO-1 task-2] colMessageXMLSignatureSecurityPolicyRule : SAML protocol message was not signed, skipping XML signature processing
shinyproxy-server_1  | 2021-02-15 21:03:14.816 DEBUG 1 --- [  XNIO-1 task-2] o.s.security.saml.util.SAMLUtil          : Found endpoint org.opensaml.saml2.metadata.impl.AssertionConsumerServiceImpl<strong i="7">@6531c789</strong> for request URL https://my.company.com/app/saml/SSO based on location attribute in metadata
shinyproxy-server_1  | 2021-02-15 21:03:14.816 DEBUG 1 --- [  XNIO-1 task-2] o.s.s.saml.storage.HttpSessionStorage    : Message a17g5ahb0gieeh9b4e48ff6a3d454jj found in session hXmYJ_E8wf6F2plFsHP_TwIZS1Cg6n2Vu4wD4i2H, clearing
shinyproxy-server_1  | 2021-02-15 21:03:14.817 DEBUG 1 --- [  XNIO-1 task-2] o.s.s.s.w.WebSSOProfileConsumerImpl      : Verifying issuer of the Response
shinyproxy-server_1  | 2021-02-15 21:03:14.817 DEBUG 1 --- [  XNIO-1 task-2] o.s.s.s.w.WebSSOProfileConsumerImpl      : Verifying signature
shinyproxy-server_1  | 2021-02-15 21:03:14.820 DEBUG 1 --- [  XNIO-1 task-2] o.s.s.s.t.MetadataCredentialResolver     : Added 1 credentials resolved from metadata of entity http://auth.company.com/adfs/services/trust
shinyproxy-server_1  | 2021-02-15 21:03:14.826 DEBUG 1 --- [  XNIO-1 task-2] o.s.s.s.w.WebSSOProfileConsumerImpl      : Processing Bearer subject confirmation
shinyproxy-server_1  | 2021-02-15 21:03:14.836 DEBUG 1 --- [  XNIO-1 task-2] o.s.s.s.w.WebSSOProfileConsumerImpl      : Validation of authentication statement in assertion failed, skipping
shinyproxy-server_1  | org.springframework.security.authentication.CredentialsExpiredException: Authentication statement is too old to be used with value 2021-02-15T15:51:35.161Z
                        ...
shinyproxy-server_1  | 2021-02-15 21:03:14.839 DEBUG 1 --- [  XNIO-1 task-2] o.s.s.saml.SAMLAuthenticationProvider    : Error validating SAML message
shinyproxy-server_1  |
shinyproxy-server_1  | org.opensaml.common.SAMLException: Response doesn't have any valid assertion which would pass subject validation
                       ...
shinyproxy-server_1  |
shinyproxy-server_1  | 2021-02-15 21:03:14.841  INFO 1 --- [  XNIO-1 task-2] o.s.security.saml.log.SAMLDefaultLogger  : AuthNResponse;FAILURE;XXX.XX.XXX.XX;https://my.company.com/app;http://auth.company.com/adfs/services/trust;;;org.opensaml.common.SAMLException: Response doesn't have any valid assertion which would pass subject validation
shinyproxy-server_1  |  at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:265)
                       ...
shinyproxy-server_1  |
shinyproxy-server_1  | 2021-02-15 21:03:14.842  INFO 1 --- [  XNIO-1 task-2] e.o.containerproxy.service.UserService   : Authentication failure [user: ] [error: Error validating SAML message]
shinyproxy-server_1  | 2021-02-15 21:03:14.848 DEBUG 1 --- [  XNIO-1 task-2] o.s.security.saml.SAMLProcessingFilter   : Authentication request failed: org.springframework.security.authentication.AuthenticationServiceException: Error validating SAML message
shinyproxy-server_1  |
shinyproxy-server_1  | org.springframework.security.authentication.AuthenticationServiceException: Error validating SAML message
                       ...
shinyproxy-server_1  |
shinyproxy-server_1  | 2021-02-15 21:03:14.849 DEBUG 1 --- [  XNIO-1 task-2] o.s.security.saml.SAMLProcessingFilter   : Updated SecurityContextHolder to contain null Authentication
shinyproxy-server_1  | 2021-02-15 21:03:14.849 DEBUG 1 --- [  XNIO-1 task-2] o.s.security.saml.SAMLProcessingFilter   : Delegating to authentication failure handler org.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler<strong i="8">@19dec0b4</strong>
shinyproxy-server_1  | 2021-02-15 21:03:14.858 ERROR 1 --- [  XNIO-1 task-2] org.thymeleaf.TemplateEngine             : [THYMELEAF][XNIO-1 task-2] Exception processing template "/": Error resolving template [/], template might not exist or might not be accessible by any of the configured Template Resolvers
shinyproxy-server_1  | org.thymeleaf.exceptions.TemplateInputException: Error resolving template [/], template might not exist or might not be accessible by any of the configured Template Resolvers
                       ...
shinyproxy-server_1  |
shinyproxy-server_1  | 2021-02-15 21:03:14.861 ERROR 1 --- [  XNIO-1 task-2] io.undertow.request                      : UT005023: Exception handling request to /app/error
shinyproxy-server_1  |
shinyproxy-server_1  | org.springframework.web.util.NestedServletException: Request processing failed; nested exception is org.thymeleaf.exceptions.TemplateInputException: Error resolving template [/], template might not exist or might not be accessible by any of the configured Template Resolvers

Diese Sequenz wird 7 Mal in etwa 2 Sekunden wiederholt, bevor ShinyProxy aufgibt und mich wie oben gezeigt auf eine generische Springboot-Fehlerseite bringt. Zwei Kuriositäten:

1) org.springframework.security.authentication.CredentialsExpiredException: Authentication statement is too old to be used with value 2021-02-15T15:51:35.161Z -- dies scheint die Wurzel des Problems zu sein, aber ich bin mir nicht sicher, ob dies ein Problem auf der IdP-Seite oder auf der ShinyProxy-Seite ist

2) 2021-02-15 21:03:14.861 ERROR 1 --- [ XNIO-1 task-2] io.undertow.request : UT005023: Exception handling request to /app/error -- es scheint, dass meine Fehlervorlage nicht richtig geladen wird. Wenn dem so wäre, könnte ich einen Link zur "Logout"-Seite einfügen, auf die Benutzer klicken könnten, um ihre Sitzung zurückzusetzen (nicht sicher, ob das funktionieren würde, nur eine Ahnung).

Irgendwelche Ideen?

jat255 am 16. Feb. 2021

Ähnliche Links:

1) https://stackoverflow.com/questions/48289763/spring-security-infinite-loop-after-initial-login-and-timeout
2) https://stackoverflow.com/questions/30528636/idp-initiated-saml-login-error-authentication-statement-is-too-old-to-be-used

Link 2 schlägt einige Lösungen vor: (1) Richten Sie maxAuthenticationAge auf die Lebensdauer des ADFS aus oder (2) setzen Sie forceAuthN auf true

Sind dies innerhalb der ShinyProxy-Konfiguration möglich oder sehe ich einen benutzerdefinierten Build an, der dafür erforderlich ist?

jat255 am 16. Feb. 2021

Hallo @jat255

Danke für deinen ausführlichen Bericht und deine Recherche! Dies ist ein ziemlicher Zufall: Genau das gleiche Problem hatte ich auch bei einem unserer Bereitstellungen. Gestern habe ich die gleichen Lösungen gefunden wie du, musste ich nur testen :)

Das Setzen der Option forceAuthN löst tatsächlich das Problem auf unserer Seite. Der einzige Nachteil besteht darin, dass der Benutzer gezwungen ist, seine vollständigen Anmeldeinformationen erneut anzugeben, während ADFS glaubt, dass die Anmeldeinformationen des Benutzers noch "frisch genug" sind. Aus dem von Ihnen bereitgestellten Link geht außerdem hervor, dass einige IDPs diese Option ignorieren (z. B. Google). Sie können forceAuthN aktivieren, indem Sie es in Ihrer Saml-Konfiguration angeben:

proxy:
  saml:
    idp-metadata-url: ... 
    ....
    force-authn: true

Diese Option ist auf unserer Website noch nicht dokumentiert, ich kümmere mich darum.

Die Angabe der Option maxAuthenticationAge ist in ShinyProxy noch nicht implementiert. Da ich jedoch einen Wert in dieser Option sehe (z. B. die Verwendung von Google als IDP), werde ich eine Option dafür implementieren.

Ich werde auch versuchen, ein nützlicheres Verhalten im Fall von CredentialsExpiredException bereitzustellen.

LEDfan am 17. Feb. 2021

@LEDfan vielen Dank für Ihre schnelle Antwort und Lösung! Ich habe diese Änderung implementiert, aber jetzt muss ich 24 Stunden warten, um zu sehen, ob es funktioniert :smirk: Ich habe zumindest bestätigt, dass ich ForceAuthn="true" in der SAML-Nutzlast sehe, also funktioniert die Option definitiv auf dem ShinyProxy Seite.

Ich denke, die Option forceAuthN wird für unsere Benutzer nicht allzu schwer sein, da die meisten unserer Benutzer die Unternehmensauthentifizierung verwenden, die mit der automatischen Windows-Anmeldeinformationsverwaltung verbunden ist, sodass sie keine Passwörter eingeben müssen, um Zugriff zu erhalten SAML-geschützte Ressourcen. Ich melde mich hier in ein paar Tagen wieder, um Ihnen mitzuteilen, ob es in unserem Fall funktioniert hat.

jat255 am 18. Feb. 2021

👍1

Dies scheint in den letzten Tagen zu funktionieren (ich habe den Fehler nicht mehr gesehen), also werde ich fortfahren und dies schließen. Danke noch einmal!

jat255 am 22. Feb. 2021

🚀1

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen

Shinyproxy: Zeitüberschreitung bei SAML-Authentifizierung (?) Fehler

Alle 6 Kommentare

Verwandte Themen