guacamole SAML 1.4 authentication loop - saml

Question

I have a working setup with ms app proxy in front end internet facing and guacamole with SAML ext of 1.3 with below guacamole.properties file.
# Available as "Login URL" from the Azure Active Directory Console
saml-idp-metadata-url: file:///etc/guacamole/metadata.xml
# The Entity ID you assigned to this application
saml-entity-id: https://example.privatedomain.com
# The redirect URL
saml-callback-url: https://example-public.msappproxy.net/
saml-debug: true
Now when you use https://example-public.msappproxy.net/ it redirects to azure for authentication and then redirects to guacamole but in the browser the URI remains as "https://example-public.msappproxy.net/#/?responseHash=E666C2CD34669C06776889QCJKADTAOIUD8A763FD0B77F"
But with SAML 1.4 this setup ends up in loop from ms to guacamole and back.
MS App proxy setup is exactly the same. Are there any additional config required at guacamole or MS end?
NOTE: Just a brief MS app proxy has got both reply URI set "https://example.privatedomain.com" and "https://example-public.msappproxy.net/" but the MS app proxy one as default.
Below is the error in guacamole logs for 1.4
ERROR c.onelogin.saml2.authn.SamlResponse - The response was received at https://example.privatedomain.com/api/ext/saml/callback instead of https://example-public.msappproxy.net/api/ext/saml/callback

Answer 1

The SAML extension knows the response is being received at https://example.privatedomain.com instead of https://example-public.msappproxy.net.
In the SAML extension, the default setting for saml-strict is true, which requires valid certificates, but it also requires the two URLs to match. Setting saml-strict: false will remove the requirement that the URLs must match.
The same would happen if you had a Guacamole serving over HTTP with a load-balancer handling HTTPS, the Guacamole server would receive the response at http://guacamole.privatedomain.com instead of https://guacamole.privatedomain.com and it would fail the "strict" check.
You should also consider changing your saml-idp-metadata-url to directly download the metadata from Azure/Microsoft in case it gets updated. You can find the metadata URL in the Azure Console.