You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by Vieri <re...@yahoo.com.INVALID> on 2022/03/10 12:32:04 UTC
SAML SP metadata
Hi,
I'm trying to configure SAML in Guacamole.
The IdP admin is asking for a metadata XML file or the following data so the SP metadata can be generated:
- EntityId: I guess I can make that up just as long as I set it in guacamole.properties as saml-entity-id, right?
- public certificate and encryption: I should send the public cert hosted on https://my-guac-server.com, correct?
- SAML endpoints and types of binding: that's what I don't fully grasp. I've seen some SP metadata sample files with tags such as:
init:RequestInitiator
idpdisc:DiscoveryResponse
ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="...
SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="...
SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="...
AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="...
So what are the SAML endpoints and bindings for Apache Guacamole?
Does Guacamole generate an SP metadata XML file?
Regards,
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
On Sunday, March 27, 2022, 05:32:07 PM GMT+2, Vieri <re...@yahoo.com.invalid> wrote:
>
> I created this:
> https://issues.apache.org/jira/browse/GUACAMOLE-1565
Hi again,
Regarding SAML there's another important feature I haven't requested on Jira yet.
I require the guacamole application to allow access to its service ONLY if the user logging in belongs to a specific group sent in via the "groups attribute". In other words if the user does not belong to MY_REQUIRED_GROUP then it should NOT be granted access whatsoever.
I'm attaching a patch which does just that although I'd rather show the denied user a message of some sort (and not just throw an exception).
And yes, the required group name should be retrieved with confService.
I know you have a lot of other areas to cover and that making changes to an authentication process can be tricky as you don't want to inadvertantly create a vulnerability, but could you please let me know at least if the feature request I already submited regarding the private key and this one are of any interest at all to the community so that I can decide whether to keep patching my guacamole installation long-term or not?
Thanks,
Vieri
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
On Saturday, March 26, 2022, 06:15:38 PM GMT+1, Vieri <re...@yahoo.com.invalid> wrote:
>> samlMap.put(SettingsBuilder.SP_X509CERT_PROPERTY_KEY, "SP_PEM_public_key_string");
>> samlMap.put(SettingsBuilder.SP_PRIVATEKEY_PROPERTY_KEY, "SP_PEM_private_key_string");
>
> Just to let you know that the NameID bit was solved by the IdP admin. Everything is now working with encryption with the quick hack that I mentioned above.
>
> Would it be useful to open a feature request?
I created this:
https://issues.apache.org/jira/browse/GUACAMOLE-1565
Simple patch works for me:
https://issues.apache.org/jira/secure/attachment/13041660/saml-private-key-file.patch
I just need to specify the file name in guacamole.properties with something like this:
saml-private-key-file: /etc/ssl/tomcat/server.key
Of course, one could also implement reading the SP metadata xml file, but I needed to just read the PEM cert and only that in the OS.
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
On Saturday, March 26, 2022, 12:34:32 AM GMT+1, Vieri <re...@yahoo.com.invalid> wrote:
> samlMap.put(SettingsBuilder.SP_X509CERT_PROPERTY_KEY, "SP_PEM_public_key_string");
> samlMap.put(SettingsBuilder.SP_PRIVATEKEY_PROPERTY_KEY, "SP_PEM_private_key_string");
Just to let you know that the NameID bit was solved by the IdP admin. Everything is now working with encryption with the quick hack that I mentioned above.
Would it be useful to open a feature request?
Regards,
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
If I edit the source code and change this file:
extensions/guacamole-auth-sso/modules/guacamole-auth-sso-saml/src/main/java/org/apache/guacamole/auth/saml/conf/ConfigurationService.java
so it contains these hard-coded values within getSamlSettings() (just for testing -- I used my public and private keys in PEM format):
samlMap.put(SettingsBuilder.SP_X509CERT_PROPERTY_KEY, "SP_PEM_public_key_string");
samlMap.put(SettingsBuilder.SP_PRIVATEKEY_PROPERTY_KEY, "SP_PEM_private_key_string");
then Guacamole can successfully decode encrypted SAML responses. The user can finally log into Guacamole without being constantly redirected to the IdP as described in my previous posts.
However, it seems that Guacamole barfs on the decoded replies as it aborts with an internal error.
The full log (too big to send to the list) is here:
https://drive.google.com/file/d/1J1XVhqaXerZahcIni5SaRr-tr-CcCbLY/view?usp=sharing
I'm supposed to get the username in NameID as in the following line, but it is encoded:
536 [https-openssl-apr-8543-exec-1] DEBUG c.onelogin.saml2.authn.SamlResponse - SAMLResponse has NameID --> AAdzZWNyZXQxvHS57wt8MVHgMnEIP1HFJYlci4R7gdXOwCya816aStAc7KWFAV4LPQviY4b+gqBmGBmFb/exUCRWFenjKvAjwPgAn6Iec73JpEbLRkXmG+xaow2bK2Kom/IIaa7CyyXsQWDmaJ/1P4EDUs7RZEskehMsta1C+g==
So my first question is: how can guacamole decode it as it is already doing with the rest of the messages?
In any case, the log line right after that actually *does* contain the username in clear text:
538 [https-openssl-apr-8543-exec-1] DEBUG c.onelogin.saml2.authn.SamlResponse - SAMLResponse has attributes: {urn:oid:2.5.4.3=[MYUSERNAME], IDP=[INTERNAL]}
Can this be used somehow as NameID (ie. NameID = MYUSERNAME)?
Everything after that in the log is "ruined" because of the encrypted username which is also too long of a string (so postgresql fails in my case).
740 [https-openssl-apr-8543-exec-6] INFO o.a.g.r.auth.AuthenticationService - User "aadzzwnyzxqxvhs57wt8mvhgmneip1hfjylci4r7gdxowcya816astac7kwfav4lpqviy4b+gqbmgbmfb/exucrwfenjkvajwpgan6iec73jpeblrkxmg+xaow2bk2kom/iiaa7cyyxsqwdmaj/1p4edus7rzeskehmsta1c+g==" successfully authenticated from 10.1.1.30.
819 [https-openssl-apr-8543-exec-6] ERROR o.a.g.rest.RESTExceptionMapper - Unexpected internal error:
### Error updating database. Cause: org.postgresql.util.PSQLException: ERROR: value too long for type character varying(128)
Regards,
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
On Friday, March 25, 2022, 12:03:21 PM GMT+1, Vieri <re...@yahoo.com.invalid> wrote:
>
>Is the current implementation of guacamole-auth-sso-saml-1.4.0 capable of decrypting SAML responses with the SP's private key?
Maybe when
https://github.com/apache/guacamole-client/blob/c63c02d645abf763db00de9174b4537739f52319/extensions/guacamole-auth-sso/modules/guacamole-auth-sso-saml/src/main/java/org/apache/guacamole/auth/saml/conf/ConfigurationService.java#L342
sets properties such as SP_ENTITYID_PROPERTY_KEY, it could also try to set properties such as:
SP_X509CERT_PROPERTY_KEY
SP_PRIVATEKEY_PROPERTY_KEY
I'm not sure if other properties such as SECURITY_SIGN_METADATA are also required or not.
Any ideas?
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
Is the current implementation of guacamole-auth-sso-saml-1.4.0 capable of decrypting SAML responses with the SP's private key?
If it is, according to the Tomcat log there seems to be a problem specifying or accessing the SP's private key.
[https-openssl-apr-8543-exec-1] 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_ae784bc7-28a7-4b08-a064-628d530e0137" Version="2.0" IssueInstant="2022-03-25T10:38:43Z" Destination="https://idp.domain.org/idp/profile/SAML2/Redirect/SSO" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://guacamole.domain.org:8543/HMNsg/api/ext/saml/callback"><saml:Issuer>https://guacamole.domain.org:8543/HMNsg</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>
[https-openssl-apr-8543-exec-1] DEBUG o.a.g.a.f.FileAuthenticationProvider - User mapping file "/etc/guacamole/user-mapping.xml" does not exist and will not be read.
[https-openssl-apr-8543-exec-1] DEBUG o.a.g.r.auth.AuthenticationService - Anonymous authentication attempt from 10.215.111.210 failed.
[https-openssl-apr-8543-exec-1] DEBUG o.a.g.rest.RESTExceptionMapper - Client request rejected: Redirecting to SAML IdP.
[https-openssl-apr-8543-exec-6] DEBUG o.a.g.resource.ResourceServlet - Resource not modified: "/app/ext/HMANbranding/images/guac-tricolor.png"
[https-openssl-apr-8543-exec-9] WARN o.a.g.a.s.a.AssertionConsumerServiceResource - Authentication attempted with an invalid SAML response: Current SAML settings are insufficient to decrypt/parse the received SAML response.
[https-openssl-apr-8543-exec-9] DEBUG o.a.g.a.s.a.AssertionConsumerServiceResource - Received SAML response failed validation.
org.apache.guacamole.GuacamoleServerException: Current SAML settings are insufficient to decrypt/parse the received SAML response.
at org.apache.guacamole.auth.saml.acs.SAMLService.processResponse(SAMLService.java:173)
at org.apache.guacamole.auth.saml.acs.AssertionConsumerServiceResource.processSamlResponse(AssertionConsumerServiceResource.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:124)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:167)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:176)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:475)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:397)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:81)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:255)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:234)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:684)
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:394)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:346)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:366)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:319)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:205)
at com.google.inject.servlet.ServletDefinition.doServiceImpl(ServletDefinition.java:290)
at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:280)
at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:184)
at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:89)
at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:85)
at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:121)
at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:133)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source)
at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown Source)
at org.apache.catalina.core.StandardContextValve.invoke(Unknown Source)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Unknown Source)
at org.apache.catalina.core.StandardHostValve.invoke(Unknown Source)
at org.apache.catalina.valves.ErrorReportValve.invoke(Unknown Source)
at org.apache.catalina.valves.RemoteIpValve.invoke(Unknown Source)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Unknown Source)
at org.apache.catalina.core.StandardEngineValve.invoke(Unknown Source)
at org.apache.catalina.connector.CoyoteAdapter.service(Unknown Source)
at org.apache.coyote.http2.StreamProcessor.service(Unknown Source)
at org.apache.coyote.AbstractProcessorLight.process(Unknown Source)
at org.apache.coyote.http2.StreamProcessor.process(Unknown Source)
at org.apache.coyote.http2.StreamRunnable.run(Unknown Source)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(Unknown Source)
at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)
Caused by: com.onelogin.saml2.exception.SettingsException: No private key available for decrypt, check settings
at com.onelogin.saml2.authn.SamlResponse.decryptAssertion(SamlResponse.java:1204)
at com.onelogin.saml2.authn.SamlResponse.loadXmlFromBase64(SamlResponse.java:168)
at com.onelogin.saml2.authn.SamlResponse.<init>(SamlResponse.java:118)
at org.apache.guacamole.auth.saml.acs.SAMLService.processResponse(SAMLService.java:152)
... 53 common frames omitted
If I use a SAML Firefox add-on to inspect the SAML messages, I can see that the IdP replies with a SAML string containing an encrypted message which apparently Guacamole-saml is not capable of decrypting.
It finally ends with a call to https://infranet.hospitalmanacor.org:8543/HMANsg/api/tokens and a "HTTP/2.0 403 Forbidden" message which then redirects the client browser back to the IdP (redirection loop).
So, please let me know if anyone is already using encrypted messages in Guacamole-SAML or not.
If it's not implemented yet, any plans to do so or ideas on how to do it?
Any alternative ideas such as maybe installing and configuring Shibboleth from https://shibboleth.net/downloads/service-provider/ and then Shibbolize the Guacamaole Tomcat web service (https://shibboleth.atlassian.net/wiki/spaces/SHIB2/pages/2577072357/NativeSPEnableApplication)?
Regards,
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
I can't get past this. I keep getting the "No private key available for decrypt, check settings" as seen here below:
[https-openssl-apr-8543-exec-2] WARN o.a.g.a.s.a.AssertionConsumerServiceResource - Authentication attempted with an invalid SAML response: Current SAML settings are insufficient to decrypt/parse the received SAML response.
[https-openssl-apr-8543-exec-2] DEBUG o.a.g.a.s.a.AssertionConsumerServiceResource - Received SAML response failed validation.
org.apache.guacamole.GuacamoleServerException: Current SAML settings are insufficient to decrypt/parse the received SAML response.
at org.apache.guacamole.auth.saml.acs.SAMLService.processResponse(SAMLService.java:173)
at org.apache.guacamole.auth.saml.acs.AssertionConsumerServiceResource.processSamlResponse(AssertionConsumerServiceResource.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:124)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:167)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:176)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:475)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:397)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:81)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:255)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:234)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:684)
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:394)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:346)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:366)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:319)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:205)
at com.google.inject.servlet.ServletDefinition.doServiceImpl(ServletDefinition.java:290)
at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:280)
at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:184)
at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:89)
at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:85)
at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:121)
at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:133)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source)
at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown Source)
at org.apache.catalina.core.StandardContextValve.invoke(Unknown Source)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Unknown Source)
at org.apache.catalina.core.StandardHostValve.invoke(Unknown Source)
at org.apache.catalina.valves.ErrorReportValve.invoke(Unknown Source)
at org.apache.catalina.valves.RemoteIpValve.invoke(Unknown Source)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Unknown Source)
at org.apache.catalina.core.StandardEngineValve.invoke(Unknown Source)
at org.apache.catalina.connector.CoyoteAdapter.service(Unknown Source)
at org.apache.coyote.http2.StreamProcessor.service(Unknown Source)
at org.apache.coyote.AbstractProcessorLight.process(Unknown Source)
at org.apache.coyote.http2.StreamProcessor.process(Unknown Source)
at org.apache.coyote.http2.StreamRunnable.run(Unknown Source)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(Unknown Source)
at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)
Caused by: com.onelogin.saml2.exception.SettingsException: No private key available for decrypt, check settings
at com.onelogin.saml2.authn.SamlResponse.decryptAssertion(SamlResponse.java:1204)
at com.onelogin.saml2.authn.SamlResponse.loadXmlFromBase64(SamlResponse.java:168)
at com.onelogin.saml2.authn.SamlResponse.<init>(SamlResponse.java:118)
at org.apache.guacamole.auth.saml.acs.SAMLService.processResponse(SAMLService.java:152)
... 53 common frames omitted
Which private key does the application need? Is it the private key of the public certificate on the Guacamole (SP) server?
Isn't the config in server.xml (tomcat) enough? Does the Guacamole SAML module use the certs defined in <Certificate> within Tomcat's server.xml?
How can I debug this further?
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
On Tuesday, March 22, 2022, 11:26:59 PM GMT+1, Vieri <re...@yahoo.com.invalid> wrote:
>"No private key available for decrypt, check settings"
How does the certificate bit work in layman's terms.
My guacamole config is:
extension-priority: saml
saml-idp-metadata-url: https://idp.domain.org/idp/shibboleth
saml-entity-id: https://guacamole.domain.org:8543/HMNsg
saml-callback-url: https://guacamole.domain.org:8543/HMNsg
saml-debug: true
and https://idp.domain.org/idp/shibboleth contains a set of 3 certificates as in this model:
<EntityDescriptor entityID="https://idp.domain.org/idp/shibboleth">
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
<Extensions>
<shibmd:Scope regexp="false">domain.org</shibmd:Scope>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
XXX
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
XXX
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="encryption">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
XXX
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://idp.domain.org/idp/profile/SAML1/SOAP/ArtifactResolution" index="1"/>
<ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://idp.domain.org/idp/profile/SAML2/SOAP/ArtifactResolution" index="2"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://idp.domain.org/idp/profile/SAML2/Redirect/SLO"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.domain.org/idp/profile/SAML2/POST/SLO"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://idp.domain.org/idp/profile/SAML2/POST-SimpleSign/SLO"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://idp.domain.org:8443/idp/profile/SAML2/SOAP/SLO"/>
<SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://idp.domain.org/idp/profile/Shibboleth/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.domain.org/idp/profile/SAML2/POST/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://idp.domain.org/idp/profile/SAML2/POST-SimpleSign/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://idp.domain.org/idp/profile/SAML2/Redirect/SSO"/>
</IDPSSODescriptor>
<AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
<Extensions>
<shibmd:Scope regexp="false">domain.org</shibmd:Scope>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
XXX
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
XXX
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="encryption">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
XXX
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://idp.domain.org/idp/profile/SAML1/SOAP/AttributeQuery"/>
</AttributeAuthorityDescriptor>
</EntityDescriptor>
I'm running Guacamole with Tomcat on the SP, and the server.xml file contains:
<Connector port="8543" protocol="org.apache.coyote.http11.Http11AprProtocol"
connectionTimeout="20000"
URIEncoding="UTF-8"
maxThreads="150" SSLEnabled="true" >
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
<SSLHostConfig>
<Certificate certificateKeyFile="/etc/ssl/tomcat/server.key"
certificateFile="/etc/ssl/tomcat/server.crt"
certificateChainFile="/etc/ssl/CA-HMN/cacert.pem"
type="RSA" />
</SSLHostConfig>
</Connector>
The IdP admin ask me for the SP's public cert, so I sent him /etc/ssl/tomcat/server.crt.
If I still get the "No private key available for decrypt, check settings" message what does that mean?
Regards,
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
On Tuesday, March 22, 2022, 11:15:10 PM GMT+1, Vieri <re...@yahoo.com.invalid> wrote:
>"No private key available for decrypt, check settings"
OK, scratch my last post. I think there's been a cert mixup between the SP and IdP.
Either one is using the wrong certificate.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
On Tuesday, March 22, 2022, 06:00:26 PM GMT+1, Vieri <re...@yahoo.com.invalid> wrote:
> My IdP has just now changed something (probably certificates), and I'm now seeing this in my guacamole logs while in a redirection loop between SP and IdP:
> "Current SAML settings are insufficient to decrypt/parse the received SAML response"
Sorry, I didn't see the explicit message further down in the log:
"No private key available for decrypt, check settings"
My guacamole settings regarding SAML are:
extension-priority: saml
saml-idp-metadata-url: https://idp.domain.org/idp/shibboleth
saml-entity-id: https://guacamole.domain.org:8543/HMNsg
saml-callback-url: https://guacamole.domain.org:8543/HMNsg
saml-debug: true
What am I missing?
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
Thanks for clearing that up.
I'm using JDBC postgresql now.
My IdP has just now changed something (probably certificates), and I'm now seeing this in my guacamole logs while in a redirection loop between SP and IdP:
"Current SAML settings are insufficient to decrypt/parse the received SAML response"
What are the possible causes that trigger this message?
(I sent guacamole's public cert to the IdP.)
Thanks,
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Nick Couchman <vn...@apache.org>.
On Sun, Mar 20, 2022 at 7:37 AM Vieri <re...@yahoo.com.invalid> wrote:
>
> On Sunday, March 20, 2022, 11:53:19 AM GMT+1, Vieri
> <re...@yahoo.com.invalid> wrote:
>
> > This is my current guacamole.properties
>
> If I replace LDAP connection provisioning with a Postgresql backend, I get
> the expected result: connections are properly loaded even when
> authenticating with SAML.
> So I guess I'm better off migrating from LDAP to Postgresql.
>
>
Vieri,
First, thanks for keeping the thread up-to-date and letting everyone know
what worked for you - this is very helpful to the entire community.
Regarding the LDAP module - it won't "stack" with the SSO module in the
same way that the JDBC module does for what you're trying to do. This is
because the LDAP module *always* uses the authentication information of the
user who is logging in to find both group membership and connection
information. The search DN and password are only used to locate the LDAP
object of the user logging in, and then the connection is re-bound with the
credentials of the user who is authenticating to Guacamole. This requires
that the password be provided for the user logging in, and since the SSO
modules don't use a password (at least not directly with Guacamole), and
since successful authentication with one module precludes authentication
from being evaluated in other modules, this won't work - the LDAP module
will never be evaluated for authentication when SSO is used, and, even if
it were, there would be no password provided to it, so it would always fail.
So, yes, if you intend to use SSO to log in to Guacamole, you will need to
store connection data in JDBC, or possibly use the JSON module to
dynamically write it with another (SSO-integrated) service.
-Nick
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
On Sunday, March 20, 2022, 11:53:19 AM GMT+1, Vieri <re...@yahoo.com.invalid> wrote:
> This is my current guacamole.properties
If I replace LDAP connection provisioning with a Postgresql backend, I get the expected result: connections are properly loaded even when authenticating with SAML.
So I guess I'm better off migrating from LDAP to Postgresql.
Thanks,
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
I finally have SAML working with my Guacamole installation. The problem was on the IdP side as they were not using the right callback URL and they were setting the user name/ID in a custom attribute instead of using nameID.
Now that I can log into Guacamole with the IdP via SAML, I'm unable to provision connections.
This is my current guacamole.properties:
guacd-hostname: 127.0.0.1
guacd-port: 4822
api-session-timeout: 1
ldap-hostname: 10.x.x.x
ldap-port: 636
ldap-encryption-method: ssl
ldap-user-base-dn: cn=Users,dc=domain,dc=org
ldap-config-base-dn: cn=Users,dc=domain,dc=org
ldap-group-base-dn: cn=Users,dc=domain,dc=org
ldap-username-attribute: cn
ldap-user-search-filter: (|(objectClass=guac*)(cn=hmsg*))
ldap-max-search-results: 9959000
ldap-search-bind-dn: cn=binduser,cn=Users,dc=domain,dc=org
ldap-search-bind-password: secret
extension-priority: saml
saml-idp-metadata-url: https://idp.domain.org/idp/shibboleth
saml-entity-id: https://guacamole.domain.org:8543/HMsg
saml-callback-url: https://guacamole.domain.org:8543/HMsg
saml-debug: true
saml-strict: false
This is my extensions dir:
# ls extensions/
branding.jar customurls.jar guacamole-auth-ldap-1.1.0.jar guacamole-auth-sso-saml-1.4.0.jar
Yes, I need to use the 1.1.0 version of the LDAP module.
Without SAML (just LDAP), this setup works fine even if I remove ldap-search-bind-dn. Users can authenticate via LDAP and the connections are provisioned from Active Directory.
If I activate SAML, authentication works but no connections are provisioned.
I understand that ldap-config-base-dn is used for retrieving connection data, but catalina.out does not show that guacamole is even trying to retrieve that data.
Correct me if I'm wrong, but SAML only "tells" Guacamole that the client can login with nameID -- there is no knowledge of the password.
So how can Guacamole retrieve connection data for the logged-in user with ldap-config-base-dn?
This is why I added the ldap-search-bind-* parameters.
Nonetheless, there is no "ldap activity" recorded in catalina.out, so the user logs in via SAML and sees no conection details at all as none have been provided via LDAP.
I even replaced the 1.1.0 LDAP module with the 1.4.0, but I'm getting the same behavior (LDAP module is properly loaded).
Tee only thing I see in the Tomcat log is:
INFO o.a.g.r.auth.AuthenticationService - User "myuser" successfully authenticated from 10.x.x.x.
DEBUG o.a.g.a.f.FileAuthenticationProvider - User mapping file "/etc/guacamole/user-mapping.xml" does not exist and will not be read.
DEBUG o.a.g.r.auth.AuthenticationService - Login was successful for user "myuser".
DEBUG o.a.g.rest.RESTExceptionMapper - Client request rejected: Session not associated with authentication provider "saml".
What does this last error message mean?
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
By the way, my catalina.out log only shows SAML requests, but no replies. I know there are replies because a tcpdump shows https traffic between the SP and the IdP.
# tail -n 10000 /var/log/tomcat-8.5-hman/catalina.out | grep logback
09:02:21.335 [localhost-startStop-1] INFO org.apache.guacamole.log.LogModule - Loading logback configuration from "/etc/guacamole/logback.xml".
# cat logback.xml
<configuration>
<!-- Appender for debugging -->
<appender name="GUAC-DEBUG" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<!-- Log at DEBUG level -->
<root level="debug">
<appender-ref ref="GUAC-DEBUG"/>
</root>
</configuration>
Why isn't Tomcat/guacamole loggging the SAML replies?
Regards,
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
On Friday, March 18, 2022, 09:52:11 AM GMT+1, Vieri <re...@yahoo.com.invalid> wrote:
> OK, so even if I remove my LDAP authentication extension and keep ONLY the SAML SSO extension (to keep things simple) I still get a redirection loop:
>
> <infinite loop>
> DEBUG o.a.g.rest.RESTExceptionMapper - Client request rejected: Redirecting to SAML IdP.
> 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_d1e9ae45-290b-4b52-802b-484299100ac2" Version="2.0" IssueInstant="2022-03-18T07:48:25Z"
> Destination="https://idp.domain.org/idp/profile/SAML2/Redirect/SSO" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
> AssertionConsumerServiceURL="https://guacamole.domain.org/api/ext/saml/callback"><saml:Issuer>https://guacamole.domain.org</saml:Issuer><samlp:NameIDPolicy
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>
> </infinite loop>
The infinite loop between SP and IdP might be because Guacamole is not extracting the user ID in the IdP's SAML reply for some reason.
The IdP admin informed me that they are using the following attribute:
<saml2:Attribute FriendlyName="cn" Name="urn:oid:2.5.4.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string" >USERNAME</saml2:AttributeValue> </saml2:Attribute>
Is Guacamole expecting the user ID in this attribute?
Is it using another format?
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
OK, so even if I remove my LDAP authentication extension and keep ONLY the SAML SSO extension (to keep things simple) I still get a redirection loop:
<infinite loop>
DEBUG o.a.g.rest.RESTExceptionMapper - Client request rejected: Redirecting to SAML IdP.
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_d1e9ae45-290b-4b52-802b-484299100ac2" Version="2.0" IssueInstant="2022-03-18T07:48:25Z" Destination="https://idp.domain.org/idp/profile/SAML2/Redirect/SSO" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://guacamole.domain.org/api/ext/saml/callback"><saml:Issuer>https://guacamole.domain.org</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>
</infinite loop>
So this means that Guacamole is properly redirecting to the IdP web portal. On initial connection a user can authenticate with the IdP just fine,and the callback to Guacamole seems to be fine too.
The problem is that Guacamole says:
"Client request rejected: Redirecting to SAML IdP."
Because of that the user loads the IdP portal for a second, and is almost immediately redirected back to Guacamole (because the user has already authed there before).
Guacamole rejects the client once again and redirects to the SAML IdP -- hence the infinite loop.
Now, I wish Guacamole could tell me why it's rejecting the client if the user properly authenticated already with the IdP.
There's nothing in catalina.out about this.
This is what I have in guacamole.properties:
guacd-hostname: 127.0.0.1
guacd-port: 4822
api-session-timeout: 1
saml-idp-metadata-url: https://idp.domain.org/idp/shibboleth
saml-entity-id: https://guacamole.domain.org
saml-callback-url: https://guacamole.domain.org/
saml-debug: true
saml-strict: false
and this is what I have in the extensions dir:
# ls extensions/
branding.jar customurls.jar guacamole-auth-sso-saml-1.4.0.jar
How can I debug this further?
How can I know why Guacamole is actually rejecting a client already properly authenticated with the IdP?
Regards,
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
I'm afraid it still doesn't work even though this time I'm not getting an infinite loop.
I set guac SAML like this:
extension-priority: saml
saml-idp-metadata-url: https://idp.domain.org/idp/shibboleth
saml-entity-id: https://guacamole.domain.org
saml-callback-url: https://guacamole.domain.org/api/ext/saml/callback
saml-debug: true
saml-strict: false
However, I'm getting this (and only this) in the Tomcat log:
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_80dc091f-9763-41c8-ba10-8c8d221b3034" Version="2.0" IssueInstant="2022-03-17T20:59:11Z" Destination="https://idp.domain.org/idp/profile/SAML2/Redirect/SSO" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://guacamole.domain.org/api/ext/saml/callback/api/ext/saml/callback"><saml:Issuer>https://guacamole.domain.org</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>
DEBUG o.a.g.a.l.AuthenticationProviderService - Anonymous bind is not currently allowed by the LDAP authentication provider.
DEBUG o.a.g.a.f.FileAuthenticationProvider - User mapping file "/etc/guacamole/user-mapping.xml" does not exist and will not be read.
DEBUG o.a.g.r.auth.AuthenticationService - Anonymous authentication attempt from x.x.x.x failed.
DEBUG o.a.g.rest.RESTExceptionMapper - Client request rejected: Redirecting to SAML IdP.
The IdP web page shows a message like this to the client browser:
"The login service was unable to identify a compatible way to respond to the requested application. This is generally due to a misconfiguration on the part of the application and should be reported to the application's support team or owner."
Note how AssertionConsumerServiceURL was wrongly expanded. So I guess saml-callback-url should really just be https://guacamole.domain.org and nothing more.
However, as stated in my previous post, that leads me to a redirection loop between SP and IdP.
Why am I seeing this?
Is it because I have both the LDAP and the SAML extensions enabled?
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
On Thursday, March 17, 2022, 01:14:18 PM GMT+1, Tyler Marcotte <ma...@gmail.com> wrote:
> Yes, you want to use "https://<guacamole_host>/api/ext/saml/callback" as the callback URL to finish out the process.
Thanks for that!
Hope this small but important piece of information makes its way into https://guacamole.apache.org/doc/gug/saml-auth.html.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: SAML SP metadata
Posted by Tyler Marcotte <ma...@gmail.com>.
Yes, you want to use "https://<guacamole_host>/api/ext/saml/callback" as
the callback URL to finish out the process.
On Thu, Mar 17, 2022 at 4:16 AM Vieri <re...@yahoo.com.invalid> wrote:
> I finally made it past the initial redirection to the IdP.
> The IdP admin properly allowed my Guacamole SP, and now I can see that the
> client browsers are being redirected to the IdP authentication portal as
> expected.
> When the user authenticates correctly, he/she is redirected back to
> Guacamole.
>
> However, this is where it fails because the browser goes into a
> redirection loop. It is sent back to the IdP portal, but since the user is
> already authenticated there, it is immediately redirected to Guacamole, and
> so on and so forth.
>
> So I guess mu "callback" setting is wrong (or something else in my
> config). Here is my guac configt:
>
> guacd-hostname: 127.0.0.1
> guacd-port: 4822
> api-session-timeout: 1
>
> ldap-hostname: 10.0.1.35
> ldap-port: 636
> ldap-encryption-method: ssl
> ldap-user-base-dn: cn=Users,dc=domain,dc=org
> ldap-config-base-dn: cn=Users,dc=domain,dc=org
> ldap-group-base-dn: cn=Users,dc=domain,dc=org
> ldap-username-attribute: cn
> ldap-user-search-filter: ##whatever##
>
> extension-priority: saml
> saml-idp-metadata-url: https://idp.domain.org/shibboleth
> saml-entity-id: https://guacamole.domain.org
> saml-callback-url: https://guacamole.domain.org
> saml-debug: true
> #saml-strict: false
>
> I'm not sure if saml-callback-url is correct here.
> Without the SAML extension enabled, a web client can connect to
> https://guacamole.domain.org and see the Guacamole login page. The user
> can login with the LDAP credentials just fine.
>
> What should I look for?
>
> This is what shows up in the Tomcat log file over and over (loops until
> client/user closes the web page/window/tab):
>
> 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_775858fa-4352-4b54-bba8-d45edb28a31f" Version="2.0"
> IssueInstant="2022-03-16T20:50:07Z" Destination="
> https://idp.domain.org/SSO"
> ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
> AssertionConsumerServiceURL="
> https://guacamole.domain.org/api/ext/saml/callback"><saml:Issuer>
> https://guacamole.domain.org</saml:Issuer><samlp:NameIDPolicy
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> AllowCreate="true" /></samlp:AuthnRequest>
> DEBUG o.a.g.a.l.AuthenticationProviderService - Anonymous bind is not
> currently allowed by the LDAP authentication provider.
> DEBUG o.a.g.a.f.FileAuthenticationProvider - User mapping file
> "/etc/guacamole/user-mapping.xml" does not exist and will not be read.
> DEBUG o.a.g.r.auth.AuthenticationService - Anonymous authentication
> attempt from x.x.x.x failed.
> DEBUG o.a.g.rest.RESTExceptionMapper - Client request rejected:
> Redirecting to SAML IdP.
>
> Should the saml-callback-url value be "
> https://guacamole.domain.org/api/ext/saml/callback" instead?
>
> It's not mentioned in the Apache Guacamole documentation found here:
> https://guacamole.apache.org/doc/gug/saml-auth.html
>
> Regards,
>
> Vieri
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
> For additional commands, e-mail: user-help@guacamole.apache.org
>
>
Re: SAML SP metadata
Posted by Vieri <re...@yahoo.com.INVALID>.
I finally made it past the initial redirection to the IdP.
The IdP admin properly allowed my Guacamole SP, and now I can see that the client browsers are being redirected to the IdP authentication portal as expected.
When the user authenticates correctly, he/she is redirected back to Guacamole.
However, this is where it fails because the browser goes into a redirection loop. It is sent back to the IdP portal, but since the user is already authenticated there, it is immediately redirected to Guacamole, and so on and so forth.
So I guess mu "callback" setting is wrong (or something else in my config). Here is my guac configt:
guacd-hostname: 127.0.0.1
guacd-port: 4822
api-session-timeout: 1
ldap-hostname: 10.0.1.35
ldap-port: 636
ldap-encryption-method: ssl
ldap-user-base-dn: cn=Users,dc=domain,dc=org
ldap-config-base-dn: cn=Users,dc=domain,dc=org
ldap-group-base-dn: cn=Users,dc=domain,dc=org
ldap-username-attribute: cn
ldap-user-search-filter: ##whatever##
extension-priority: saml
saml-idp-metadata-url: https://idp.domain.org/shibboleth
saml-entity-id: https://guacamole.domain.org
saml-callback-url: https://guacamole.domain.org
saml-debug: true
#saml-strict: false
I'm not sure if saml-callback-url is correct here.
Without the SAML extension enabled, a web client can connect to https://guacamole.domain.org and see the Guacamole login page. The user can login with the LDAP credentials just fine.
What should I look for?
This is what shows up in the Tomcat log file over and over (loops until client/user closes the web page/window/tab):
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_775858fa-4352-4b54-bba8-d45edb28a31f" Version="2.0" IssueInstant="2022-03-16T20:50:07Z" Destination="https://idp.domain.org/SSO" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://guacamole.domain.org/api/ext/saml/callback"><saml:Issuer>https://guacamole.domain.org</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>
DEBUG o.a.g.a.l.AuthenticationProviderService - Anonymous bind is not currently allowed by the LDAP authentication provider.
DEBUG o.a.g.a.f.FileAuthenticationProvider - User mapping file "/etc/guacamole/user-mapping.xml" does not exist and will not be read.
DEBUG o.a.g.r.auth.AuthenticationService - Anonymous authentication attempt from x.x.x.x failed.
DEBUG o.a.g.rest.RESTExceptionMapper - Client request rejected: Redirecting to SAML IdP.
Should the saml-callback-url value be "https://guacamole.domain.org/api/ext/saml/callback" instead?
It's not mentioned in the Apache Guacamole documentation found here: https://guacamole.apache.org/doc/gug/saml-auth.html
Regards,
Vieri
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org