Thanks for the breakdown. I suspected the issue was between the interaction of the LDAP module and the SSO component, so that is not surprising. I am not married to LDAP as a source of AAA, so I can trim that from the flow.
I did get Keycloak/SSO working easy with Guacamole connections in JBDC. It seems like I need to manage the two "components", Authentication and Authorization in different modules then. Outside of trying to do custom crafted JWKS tokens/Encrypted JSON - I don't have the knowledge to try and do that kind of custom setup. My understanding of SSO/JBDC together is that you need 2 accounts in 2 databases. 1 account on the SSO side, 1 account on the JBDC side, with the email field used as the link. Is that the case? Either way, how do you assign connections in SSO then? Some form of group memberships? I do not see in the documentation where that sort of setup is described, though I could have missed it. Sent with Proton Mail secure email. On Thursday, November 21st, 2024 at 3:53 PM, Nick Couchman <vn...@apache.org> wrote: > On Wed, Nov 20, 2024 at 2:51 PM viktor_krumm viktor_kr...@proton.me.invalid > > wrote: > > > Hello, > > > > Apologies if this is a re-send. I'm trying to unify Guacamole with LDAP > > and Keycloak. My main goal is to get WebAuthn support with Guacamole. To do > > so, I've setup Keycloak. Keycloak and Guacamole (via OIDC) work fine. The > > issue there is I need to maintain 2 databases of accounts - Keycloak > > accounts and Guacamole accounts, and map between the two. > > > > I thought LDAP would solve that issue - a centralized database of both > > users and connections. I have LLDAP and Guacamole working just fine. I can > > create both users and connections in LLDAP, and log into Guacamole > > correctly. > > > > I cannot seem to unify all three fully, however. I have LLDAP as a User > > Federation in Keycloak. I can successfully open Guacamole, get redirected > > to Keycloak as an OIDC provider, authenticate through Keycloak with an > > LLDAP account, and return to Guacamole. > > > > My main issue is, my connections are not available. If I take my same > > database, turn off Keycloak, and revert it to just LLDAP<->Guacamole, I see > > my connections, proving they're configured just fine. But connections are > > lost when Keycloak/OIDC is reintegrated. I don't know enough about LDAP > > mappings to exactly pinpoint the problem, or if its an issue with the > > workflow between Guacamole, OIDC extension, LDAP extension, or whichever. > > Has anyone gotten this sort of thing working? Is there an easier > > integration for WebAuthn and Guacamole? > > This is a pretty often-asked question, and I suspect you're running into a > similar issue as the other folks who have asked in the past. The LDAP > authentication module has a specific behavior that leverages > LDAP's built-in security and access control to allow you to control access > to Guacamole connection data stored in LDAP. What happens during the LDAP > login flow is this: > * User enters username + password > * LDAP extension binds to LDAP with the Search DN and password configured > in guacamole.properties > * LDAP extension executes a search on the LDAP tree for the user who is > logging in, based on constraints configured in guacamole.properties > (username attribute, user search base, etc.). > * If LDAP user is successfully located, LDAP extension unbinds from > LDAP with the search DB and re-binds using the DN of the user it has > just located and the password entered by the user. > * LDAP extension then searches for Guacamole connections, groups, etc., > that are accessible to the user logging in. > > In this way, the LDAP user logging in can only see the connection data that > is accessible to them in LDAP, and, so, you can limit the connections > available to the user by simply putting the connections in LDAP locations > that they can (or cannot) read/browse/search. > > The challenge with this process is that, when a user logs in with another > extension, particularly an SSO extension where the password is not > available to Guacamole, the LDAP extension cannot bind as the user who is > logging in, and so connection data cannot be located for that user - > essentially it fails at the step of re-binding as the user and then > searching for available connections. And, currently, there is no way within > Guacamole to make the LDAP extension behave any differently. I think > there's a feature request out there for it, but no implementation of that > feature today. > > So, you have two options today: > * If you want the SSO module to work, store the connections in the JDBC > module, instead of LDAP, and use the layering available within Guacamole to > assign permissions to connections to users and/or groups from SSO. > * Drop the SSO module and just use the LDAP module, requiring users to > authenticate to Guacamole, but allowing you to leverage the LDAP connection > storage and the security built-in to LDAP. > > -Nick > > > Sent with Proton Mail secure email.
