Thanks Nick! I have finally managed to partially get this working, removing the link to the metadata url, I guess one of the values being injected was throwing things off. The final caveat being that authentication only works when initiated from the iDP (AWS SSO), authentication initiated from the guacamole app fails with a 403 on the AWS SSO side.
I'm at a loss whether this is a limitation of Guacamole or AWS SSO, being this the first time I've used SAML authentication :-). Thanks, Tom On Tue, 21 Sept 2021 at 22:19, Nick Couchman <[email protected]> wrote: > On Mon, Sep 20, 2021 at 10:52 AM Tom Werner <[email protected]> wrote: > >> Hi, >> >> Has anyone had any luck of integrating AWS SSO with Guacamole? >> > > I've actually not tried it, though I probably should. > > >> >> >> I have used 1.3 versions of Guacamole, JDBC and SAML from the project >> website. >> >> Without SAML, JDBC authentication is working, however, once SSO is >> enabled, login fails. >> >> I have configured a Custom SAML2.0 app in AWS SSO, I have configured the >> ACS to; >> >> https://guacamole.<lab-fqdn>/guacamole/api/ext/saml/callback >> >> and my audience to >> >> https://guacamole.<lab-fqdn>/guacamole/ >> >> > Seems reasonable. > > >> I have setup an attribute mapping to map name = ${user:name}. >> >> On Guacamole I have setup the following properties. The idp metadata is a >> local file as AWS SSO doesn't allow pulling this via a URL >> >> saml-idp-url: >> https://portal.sso.eu-west-2.amazonaws.com/saml/assertion/<assertion >> guid> #(also the login URL) >> saml-callback-url: https://guacamole.<lab-fqdn>/guacamole >> saml-strict: False >> saml-debug: True >> saml-entity-id: https://guacamole.<lab-fqdn>/guacamole >> saml-idp-metadata-url: file:///etc/guacamole/idp_metadata.xml >> >> When attempting to authenticate (either idp initiated or SP initiated), I >> get the following in the logs. I am redirected to the Idp and login as >> attempted, but AWS SSO raises a 403 error before completing authentication. >> Is there any way to get more verbose logs of the authentication exchange? >> > > You should be getting just about everything - might just make sure you've > also bumped up Guacamole's overall logging: > > > http://guacamole.apache.org/doc/gug/configuring-guacamole.html#webapp-logging > > >> >> Sep 20 14:43:57 <aws Ip>.eu-west-2.compute.internal server[15245]: >> 14:43:57.922 [http-nio-8080-exec-6] DEBUG org.apache.xml.security.Init - >> Registering default algorithms >> Sep 20 14:43:58 <aws Ip>.eu-west-2.compute.internal server[15245]: >> 14:43:58.086 [http-nio-8080-exec-6] DEBUG >> c.onelogin.saml2.authn.AuthnRequest - AuthNRequest --> <samlp:AuthnRequest >> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" >> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" >> ID="ONELOGIN_1228671b-15f0-4a15-95a2-40ed1ab8a02f" Version="2.0" >> IssueInstant="2021-09-20T14:43:58Z" Destination=" >> https://portal.sso.eu-west-2.amazonaws.com/saml/assertion/<assertion >> id>" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" >> AssertionConsumerServiceURL="https://guacamole >> .<lab-fqdn>/guacamole/api/ext/saml/callback/api/ext/saml/callback"><saml:Issuer> >> https://guacamole.<lab-fqdn>/guacamole</saml:Issuer><samlp:NameIDPolicy >> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" >> AllowCreate="true" /></samlp:AuthnRequest> >> Sep 20 14:43:58 <aws Ip>.eu-west-2.compute.internal server[15245]: >> 14:43:58.460 [http-nio-8080-exec-6] DEBUG >> o.a.g.a.f.FileAuthenticationProvider - User mapping file >> "/etc/guacamole/user-mapping.xml" does not exist and will not be read. >> Sep 20 14:43:58 <aws Ip>.eu-west-2.compute.internal server[15245]: >> 14:43:58.462 [http-nio-8080-exec-6] DEBUG >> o.a.g.r.auth.AuthenticationService - Anonymous authentication attempt from >> 86.13.95.8 failed. >> Sep 20 14:43:58 <aws Ip>.eu-west-2.compute.internal server[15245]: >> 14:43:58.463 [http-nio-8080-exec-6] DEBUG o.a.g.rest.RESTExceptionMapper - >> Client request rejected: Redirecting to SAML IdP. >> >> > This seems to be just the initial logs before the redirection. Does the > redirection happen at all to the IdP? Nothing in the logs after this > message, here? > > -Nick >
