On Thu, Sep 15, 2016 at 10:53 AM, Paul Cantle <[email protected]> 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
