[
https://issues.apache.org/jira/browse/GUACAMOLE-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17891213#comment-17891213
]
Mike Jumper commented on GUACAMOLE-1994:
----------------------------------------
In general, the pattern used by Guacamole for access details parallels that of
Linux/UNIX: enforcement of whether the user has access to Guacamole is enforced
purely during login. Once the user is authenticated, that session is subject to
the restrictions that were set at the time the user logged in:
* If they were disabled, they are blocked from logging in.
* If they are subject to access time windows, those can prevent login.
Thus, it should already be the case that a user will lose access to all
database-stored resources if their database user is deleted, though their
session will remain active and any connections they already started may remain
running (until killed by an admin).
Beyond that, things get more complex. We can hook into our own changes to the
"disabled" flag, but:
* There is no guarantee that external modifications to the database will not
occur.
* If a user authenticates through an external system (such as LDAP), deleting
their database user doesn't necessarily mean that they are intended to lose
access to everything. They may still have access rights to other resources
through other means, such as groups or other non-database backends.
The case for access time windows is simpler, because we can cache those
restrictions at login and it's still meaningful to enforce them on an active
session. For an overall on/off switch that can change at any moment and cannot
be predicted at time of login, I think we would need to:
# Update the {{isValid()}} check for database sessions to consider the
"disabled" flag.
# Modify the database extensions to lazily refresh cached restrictions when
servicing a call to {{isValid()}} at some reasonable, configurable interval.
That would result in regular pings to the database, though, and might not scale
well without some sort of batching.
> Disabling logins should invalidate current authentication tokens
> ----------------------------------------------------------------
>
> Key: GUACAMOLE-1994
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1994
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole
> Affects Versions: 1.5.5
> Reporter: Tribhuwan Phulera
> Priority: Minor
>
> Hi Team,
> I encountered a situation where a user's ID and password were compromised.
> Upon identifying the issue, I attempted to prevent further incidents by
> navigating to the Users section and checking the "Login Disabled" option. I
> also deleted the active session of the compromised user from the Active
> Session tab, but the sessions continued to be created repeatedly. Ultimately,
> I had to restart the Tomcat server to completely prevent that user from
> accessing the system and it asks to login again after Tomcat Server restart.
> This experience has led me to propose an improvement for the "Login Disabled"
> flag or the implementation of a different feature that allows us to log out a
> user’s current session immediately to address such scenarios effectively.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
