Hi Nick, Appreciate the reply!
Seems like the SSO-Auth extension is indeed working, however I had a problem, that my SSO-Issues mapped to the same username as guacamole was configured to use the claim, so this one is on me. After being finally able to login via SSO im guacamole, I just see an empty guacamole with a user that has no rights, logging in via my normal guacamole admin(non-sso) and navigating to users tab does not show the new sso user that should have been generated, so I could manage it, but I guess that is expected since it's an external user? I went and configured a group on guacamole and gave it full admin rights, went to authentik created a group with the same name and assigned my user to that group on authentik. However after creating the group on guacamole, while it shows in the UI, I cannot edit it anymore, there is just an infinite loading circle, here the logs of that: https://pastebin.com/V8wTxwTb Thanks for the explanation, yes the above are tomcat catalina.out logs during trying to access(edit) the group I created within guacamole, using my normal guacamole admin account (non-sso-user) The second issue, after assigning my user on authentik side to the same group as created on guacamole I cannot seem to log-in anymore at all, so there is definitely something wrong with the group 'guacamole-admin' I created within guacamole, since I cannot edit/remove it anymore nor can a sso-user sign in when it has that group assigned via oidc-issuer. Here the log of the sign-in process via sso with the user that has the guacamole-armin group assigned: https://pastebin.com/aUnFzgTR Hope this is clear, otherwise I happily provide more details. Thanks - Tobias Sent with Proton Mail secure email. On Saturday, July 5th, 2025 at 13:43, Nick Couchman <[email protected]> wrote: > On Tue, Jul 1, 2025 at 3:34 AM <[email protected]> wrote: > >> Hi, >> >> When activating SSO and having set up TOPT for the admin account, signing-in >> with SSO brings up a TOPT loginscreen from guacamole which cannot be >> completed, due to the admin account although having TOPT, that's a different >> user, so it did not work to complete TOPT for an SSO User. > > I don't quite understand the scenario, could you provide a bit more detail as > to how the user is set up and what behavior you're seeing? > >> I already reported this problem a while ago and got confirmation that this >> should already be fixed and released with 1.6.0 sadly it's still not working >> :/ >> >> Looking further in jira it seems to be that only SAML has been fixed. >> https://www.mail-archive.com/[email protected]/msg13233.html >> >> or am I missing any new config options, that I have overlooked in release >> announcements? > > In my response on the previous thread I was not certain if those changes > covered OpenID or not. Looking back at the pull request, I see that some of > the changes are implemented at the SSO extension base, which would impact all > of the modules; however, there are some SAML-specific ones. So it's possible > that this didn't actually implement everything required for OpenID to > function properly. I'll have to go back through and look at the changes more > closely. > >> It would be really nice to be able to have the admin Account secured with >> TOPT and still have SSO users. >> >> My guacamole properties for OIDC setup: >> ``` >> openid-authorization-endpoint: >> https://auth.mydomain.dev/application/o/authorize/ >> openid-client-id: XXXXX >> openid-issuer: https://auth.mydomain.dev/application/o/guacamole/ >> openid-jwks-endpoint: https://auth.mydomain.dev/application/o/guacamole/jwks/ >> openid-redirect-uri: https://guac.mydomain.dev/guacamole >> openid-scope: openid email profile >> openid-username-claim-type: preferred_usernameextension-priority: *, openid >> ``` >> I'd be happy to provide logs, but using >> ``` >> systemctl stop guacd >> /usr/local/sbin/guacd -L debug -f >> ``` >> does not bring up any logs during sign-in. > > There are two components to Guacamole - guacd, which is the "proxy" service > that translates between the remote protocols (SSH, RDP, etc.) and Guacamole, > but has nothing whatsoever to do with the client logins or interface. The > client interface is run by Tomcat (or, based on your previous post, the > Docker "guacamole" container), so you'll need to gather logs from Tomcat or > that Docker container in order to see the login details. > > -Nick > >>
