I have a few questions about the OpenID integration in Guacamole.
First of all I already successfully completed the following steps:
1. I have successfully setup OpenID Connect to use Azure AD as the OpenID
2. The login works and I end up in the web interface, however there is no access
to any settings or connections.
Now for the questions:
1. No Connections for users
When logging in, the user can not see any connections (which makes sense, as I
have to select connections the user can access when creating a database-user by
AFAIU other posts on this list, to get access to the connections or groups as a
user, this user must exist in the database with the same username, as the one
provided by OpenID
If this is correct, I assume every OpenID user *must* have a database user to
actually be able to use Guacamole?
And if so, is there any way that Guacamole can create this user automatically,
or is this something that would need to be implemented in an extension?
If this can not be done automatically, how is everyone else using OpenID Connect
and Guacamole - how do you add connections/groups/asf.?
I already tried to work with the OpenID users inside an extension as well, but
realized that an OpenID user does not have a UserContext set (it is simply
null) - is it required to have a database user for a UserContext?
2. Skip-if-unavailable not working
And another one - I tried to use the skip-if-unavailable setting with the value:
skip-if-unavailable: openid, postgresql
However, if Azure AD is not reachable (I simply disconnected the network and
guacamole runs locally), there is no redirect to the default login page.
Am I understanding this setting incorrectly or am I just putting incorrect
Thanks for any answers and thanks for developing this great tool!
Sent with ProtonMail Secure Email.
On Tue, Jun 30, 2020 at 5:25 AM monadt <[hidden email]> wrote:
For OpenID integration, yes, this is true. This is not necessarily true across Guacamole - for example, if you log in with a user from LDAP that has group membership, and those groups are created in the JDBC module and assigned privileges, then the users will get those privileges without having to have an existing JDBC entry.
However, OpenID does not currently pull in group membership from any OpenID attributes, so, for users authenticating from OpenID they will need a JDBC extension user to match and then be assigned permissions, either directly or via groups.
I'm glad you asked - the 1.2.0 version that was released late last night/early this morning (depending upon your timezone) adds this support! There is now a parameter for each of the database modules for account auto-creation:
By setting this property to "true" in guacamole.properties and then reloading the Java application, the JDBC module will automatically create entries for users who are successfully authenticated from other modules, such as OpenID.
Yeah, I'm not sure this option operates quite as you're expecting, mostly because the module doesn't do any particular check ahead of time to make sure that the OpenID server is available. This would be a challenging thing to implement with respect to the SSO modules, because the first portion of the SSO authentication takes place completely on the browser side of the connection. The SSO module redirects the user to the identity provider for authentication, the browser receives a token which it then sends back to the Guacamole Java application, and then the Guacamole java application communicates with the SSO server to validate that the token sent is correct. There would have to be some way, prior to the redirect, to determine that the SSO server is unavailable and trigger the login page, and this would have to be done completely on the server-side, with no client interaction, as it would be something that a client could likely spoof in order to try to bypass part of the authentication process.
So, we probably *could* implement some sort of initial check within the SSO modules that the SSO provider is actually available, but I'm not sure how reliable it would be, and not sure how worthwhile that actually is. Most SSO providers (including Azure AD) are fairly robust and the likelihood that they'll be unavailable is going to be pretty low.
|Free forum by Nabble||Edit this page|