OpenID Connect and Guacamole Connections/Groups

[monadt <mo...@protonmail.com.INVALID>]

Hello everyone,

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
Connect provider.

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
hand).

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
(http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/OpenID-Connect-JDBC-td5097.html#a5099%C3%A4).

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
values there?

Thanks for any answers and thanks for developing this great tool!

Best regards,

Sent with [ProtonMail](https://protonmail.com) Secure Email.

Re: OpenID Connect and Guacamole Connections/Groups

[Nick Couchman <vn...@apache.org>]

On Tue, Jun 30, 2020 at 5:25 AM monadt <mo...@protonmail.com.invalid>
wrote:

> Hello everyone,
>
> 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
>    Connect provider.
>
> 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
> hand).
>
> 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
> (
> http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/OpenID-Connect-JDBC-td5097.html#a5099%C3%A4
> ).
>
> If this is correct, I assume every OpenID user *must* have a database user
> to
> actually be able to use Guacamole?
>

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.

>
> 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?
>
>
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:

postgresql-auto-create-accounts
mysql-auto-create-accounts
sqlserver-auto-create-accounts

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.


> 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
> values there?
>
>
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.

-Nick