On Thu, Feb 10, 2022 at 11:14 AM Martin Twerski <mar...@tigunia.com> wrote:
> Upgraded from 1.3 to 1.4 where I had SAML working. I have updated the > plugin to the new sso one. I get an error when trying to use SAML auth - > [http-nio-8080-exec-2] WARN o.a.g.a.s.a.AssertionConsumerServiceResource - > Authentication attempted with an invalid SAML response: SAML response did > not pass validation: The response was received at > http://example.fqdn.com/guacamole/api/ext/saml/callback instead of > https://example.fqdn.com/api/ext/saml/callback > > > > If I set saml-strict to false, no issues with login. If I revert to 1.3 > plugin, no issues. > > > > My reverse proxy in front of Guacamole is Apache. I have followed this: > https://guacamole.apache.org/doc/0.9.7/gug/proxying-guacamole.html (The > section about “Apache and mod_proxy” as well as “Setting up the Remote IP > Valve”). > > > > My proxy is not on the same box as Guacamole. > > > > Any ideas on how to resolve this? > > > > Instead of changing the path of the application within the proxy, try > renaming "guacamole.war" to "ROOT.war" so that Tomcat serves the > application from / directly. > > > > I also recommend looking at the docs for the current release: > > > > https://guacamole.apache.org/doc/gug/reverse-proxy.html > > > > The link you reference above is a snapshot of ancient 0.9.7 docs (6+ years > ago). > > > > - Mike > > > > Mike, > > Thanks for the link to the current docs. I was using an old bookmark and > didn’t realize it was a versioned copy. > > > > I don’t think the path is the issue – it appears to be an http vs https > issue. I have switched it to the root (rename war file to ROOT.war) and now > get this error: > > [http-nio-8080-exec-4] WARN o.a.g.a.s.a.AssertionConsumerServiceResource > - Authentication attempted with an invalid SAML response: SAML response did > not pass validation: The response was received at > http://example.fqdn.com/api/ext/saml/callback instead of > https://example.fqdn.com/api/ext/saml/callback > > How do I get Guacamole to “receive the response” at https? > Try adding the "X-Forwarded-Proto" header via your proxy config. The HTTP side of the proxied connection probably can't otherwise tell that the user-facing side is actually HTTPS. - Mike
