On Thu, Sep 15, 2016 at 10:53 AM, Paul Cantle <p...@cantle.me> wrote:
> Hi All,
>
> ...
>
> I'm currently using Guacamole 0.9.9 on CentOS with the MySQL extension. All
> is working well. I'm not however using the MySQL extension for
> authentication, I'm only using it for authorisation. I'm using SSO to handle
> the authentication side of things. This is also working fine.
>

OK.

> The way the SSO plugin works is based on "username matching" to the user in
> the DB. If the names match, a login to the site is permitted, else it's
> denied and the user is shown the login screen.

This is an extension that you've written yourself then? Something with
authenticates based on username alone?

If the authentication is happening within your extension, why not
handle the disabling of users there?

> To that end, because the DB
> isn't handling authentication, disabling a user in the Guacamole GUI has no
> effect.
>

OK. Makes sense.

> I'm wondering if I can enhance the following file:
> org/glyptodon/guacamole/auth/jdbc/user/UserMapper.xml to change what happens
> when a user is disabled:
>
> ...
>
> What I would like is to rename the user to disabled_<user> when the disabled
> flag is set. I know I can script this, but I'm trying to be "clever" by
> keeping it in the GUI. Something like the following SQL statement would
> probably do the job:
>
> ...
>
> Either way, would it work, or would it possibly break everything? Happy to
> test, but would just like some thoughts from the experts if that's possible
>

Well ...

It's not that it wouldn't work - it's that it's a hack. There are
definitely better ways to accomplish this, chief among them modifying
the behavior of the code handling the disabled flag such that it
explicitly provides the behavior you're looking for.

I was recently working on a configuration option for the database auth
which, if enabled, would reject external authentication results if
that user does not have a corresponding account in the database:

https://issues.apache.org/jira/browse/GUACAMOLE-70

It might make sense to roll the behavior you describe into the above
change, such that the auth result is rejected if the user account
doesn't exist OR the user account is disabled. That said, I would be
worried about there suddenly being no way to have an account which can
be used only via external authentication (guaranteeing that the
database does not authenticate the user, but does still provide data
for that user), which was one of the driving factors for that flag.

Thanks,

- Mike

Reply via email to