Re: SAML in a loop
Hi Mike, I am experiencing the same issue here. I followed the suggestions posted, but still find myself looping. Any suggestions? On Wed, Jan 5, 2022 at 12:49 PM Tobias Heim wrote: > Hi Mike, > > great suggestion – such a simple solution – it works with that now, thanks > a lot! > > > > BR, Tobias > > > > *Von:* Mike Jumper > *Gesendet:* Mittwoch, 5. Januar 2022 17:27 > *An:* user@guacamole.apache.org > *Betreff:* Re: SAML in a loop > > > > On Wed, Jan 5, 2022, 06:32 Tobias Heim wrote: > > Hi Mike, > > > > Thanks a lot for your suggestions! I think it’s related to nginx, yes – > with the X-Forwarded-Proto and X-Forwarded-Host I got further (before, it > told me the URL for the callback would be http:/localhost:8080/…), but it > still does not work due to the following problem: > > > > 15:24:42.905 [http-nio-8080-exec-6] 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 https://myserver/*guacamole*/api/ext/saml/callback > instead of https://myserver/api/ext/saml/callback > > > > Somehow I cannot get rid of the extra /guacamole/ in that path, even when > setting all the headers you provided to me.. > > > > Do you know how to do that? > > > > Instead of altering the request path within Nginx, I would rename the .war > file to "ROOT.war". That will cause Tomcat to serve the application > directly from "/" instead of "/guacamole". > > > > - Mike > > >
AW: SAML in a loop
Hi Mike, great suggestion – such a simple solution – it works with that now, thanks a lot! BR, Tobias Von: Mike Jumper Gesendet: Mittwoch, 5. Januar 2022 17:27 An: user@guacamole.apache.org Betreff: Re: SAML in a loop On Wed, Jan 5, 2022, 06:32 Tobias Heim mailto:t.h...@spedion.de>> wrote: Hi Mike, Thanks a lot for your suggestions! I think it’s related to nginx, yes – with the X-Forwarded-Proto and X-Forwarded-Host I got further (before, it told me the URL for the callback would be http:/localhost:8080/…), but it still does not work due to the following problem: 15:24:42.905 [http-nio-8080-exec-6] 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 https://myserver/guacamole/api/ext/saml/callback instead of https://myserver/api/ext/saml/callback Somehow I cannot get rid of the extra /guacamole/ in that path, even when setting all the headers you provided to me.. Do you know how to do that? Instead of altering the request path within Nginx, I would rename the .war file to "ROOT.war". That will cause Tomcat to serve the application directly from "/" instead of "/guacamole". - Mike
Re: SAML in a loop
On Wed, Jan 5, 2022, 06:32 Tobias Heim wrote: > Hi Mike, > > > > Thanks a lot for your suggestions! I think it’s related to nginx, yes – > with the X-Forwarded-Proto and X-Forwarded-Host I got further (before, it > told me the URL for the callback would be http:/localhost:8080/…), but it > still does not work due to the following problem: > > > > 15:24:42.905 [http-nio-8080-exec-6] 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 https://myserver/*guacamole*/api/ext/saml/callback > instead of https://myserver/api/ext/saml/callback > > > > Somehow I cannot get rid of the extra /guacamole/ in that path, even when > setting all the headers you provided to me.. > > > > Do you know how to do that? > Instead of altering the request path within Nginx, I would rename the .war file to "ROOT.war". That will cause Tomcat to serve the application directly from "/" instead of "/guacamole". - Mike
AW: SAML in a loop
Hi Mike, Thanks a lot for your suggestions! I think it’s related to nginx, yes – with the X-Forwarded-Proto and X-Forwarded-Host I got further (before, it told me the URL for the callback would be http:/localhost:8080/…), but it still does not work due to the following problem: 15:24:42.905 [http-nio-8080-exec-6] 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 https://myserver/guacamole/api/ext/saml/callback instead of https://myserver/api/ext/saml/callback Somehow I cannot get rid of the extra /guacamole/ in that path, even when setting all the headers you provided to me.. Do you know how to do that? Best regards, Tobias Von: Mike Jumper Gesendet: Mittwoch, 5. Januar 2022 15:23 An: user@guacamole.apache.org Betreff: Re: SAML in a loop On Wed, Jan 5, 2022, 04:55 Nick Couchman mailto:vn...@apache.org>> wrote: On Wed, Jan 5, 2022 at 6:41 AM Tobias Heim mailto:t.h...@spedion.de>> wrote: Hey team, we upgraded guacamole from 1.3 to 1.4 – in the old version, using SAML with Duo authenticator was fine. But now it seems some information is not considered anymore as using SSO-SAML means landing in a login loop – it always forwards from https://ourguacamoleserver/api/ext/saml/login to the external address of DUO and back and again and again.. Did the callback address change from /api/ext/saml/callback to something else maybe? Do you know what may cause this issue? The only chance for me to get out of this loop was to enable the manual login window.. No, the callback address did not change. You'll probably need to look at logs for both Guacamole Client (Tomcat or whatever app server you're using) and see if there's any reason being returned by the system for the login failure. You may even need to enable some debugging - either for the web app in general or using the saml-debug property in guacamole.properties (or both) to see additional messages. https://guacamole.apache.org/doc/gug/configuring-guacamole.html#logging-within-the-web-application Tobias, are you using Nginx for SSL termination perchance? If so, try adding the following to what you already have in your Nginx config: proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-Proto $scheme; I encountered something similar recently, and I think that some of the dependency updates affected the headers required with respect to determining the true URL applicable to things like the SAML ACS. With the above, you will likely also need a RemoteIpValve entry in Tomcat's server.xml, if you don't already have it: https://guacamole.apache.org/doc/gug/reverse-proxy.html#setting-up-the-remote-ip-valve - Mike
Re: SAML in a loop
On Wed, Jan 5, 2022, 04:55 Nick Couchman wrote: > On Wed, Jan 5, 2022 at 6:41 AM Tobias Heim wrote: > >> Hey team, >> >> we upgraded guacamole from 1.3 to 1.4 – in the old version, using SAML >> with Duo authenticator was fine. >> >> But now it seems some information is not considered anymore as using >> SSO-SAML means landing in a login loop – it always forwards from >> https://ourguacamoleserver/api/ext/saml/login to the external address of >> DUO and back and again and again.. >> >> Did the callback address change from /api/ext/saml/callback to something >> else maybe? >> >> Do you know what may cause this issue? The only chance for me to get out >> of this loop was to enable the manual login window.. >> >> >> > > No, the callback address did not change. You'll probably need to look at > logs for both Guacamole Client (Tomcat or whatever app server you're using) > and see if there's any reason being returned by the system for the login > failure. You may even need to enable some debugging - either for the web > app in general or using the saml-debug property in guacamole.properties (or > both) to see additional messages. > > > https://guacamole.apache.org/doc/gug/configuring-guacamole.html#logging-within-the-web-application > Tobias, are you using Nginx for SSL termination perchance? If so, try adding the following to what you already have in your Nginx config: proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-Proto $scheme; I encountered something similar recently, and I think that some of the dependency updates affected the headers required with respect to determining the true URL applicable to things like the SAML ACS. With the above, you will likely also need a RemoteIpValve entry in Tomcat's server.xml, if you don't already have it: https://guacamole.apache.org/doc/gug/reverse-proxy.html#setting-up-the-remote-ip-valve - Mike
Re: SAML in a loop
On Wed, Jan 5, 2022 at 6:41 AM Tobias Heim wrote: > Hey team, > > we upgraded guacamole from 1.3 to 1.4 – in the old version, using SAML > with Duo authenticator was fine. > > But now it seems some information is not considered anymore as using > SSO-SAML means landing in a login loop – it always forwards from > https://ourguacamoleserver/api/ext/saml/login to the external address of > DUO and back and again and again.. > > Did the callback address change from /api/ext/saml/callback to something > else maybe? > > Do you know what may cause this issue? The only chance for me to get out > of this loop was to enable the manual login window.. > > > No, the callback address did not change. You'll probably need to look at logs for both Guacamole Client (Tomcat or whatever app server you're using) and see if there's any reason being returned by the system for the login failure. You may even need to enable some debugging - either for the web app in general or using the saml-debug property in guacamole.properties (or both) to see additional messages. https://guacamole.apache.org/doc/gug/configuring-guacamole.html#logging-within-the-web-application -Nick >
SAML in a loop
Hey team, we upgraded guacamole from 1.3 to 1.4 - in the old version, using SAML with Duo authenticator was fine. But now it seems some information is not considered anymore as using SSO-SAML means landing in a login loop - it always forwards from https://ourguacamoleserver/api/ext/saml/login to the external address of DUO and back and again and again.. Did the callback address change from /api/ext/saml/callback to something else maybe? Do you know what may cause this issue? The only chance for me to get out of this loop was to enable the manual login window.. Best regards, Tobias
