[
https://issues.apache.org/jira/browse/GUACAMOLE-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18021594#comment-18021594
]
Nick Couchman commented on GUACAMOLE-2140:
------------------------------------------
Ah, okay, I see what's going on, and I'm a little less sure that it's something
that we want to actually enable or allow. Guacamole's API sanitizes the
attributes for a user based on whether the required extensions are loaded, and
doesn't store any attributes that aren't explicitly supported by one of the
loaded extensions. So, when you do not have TOTP enabled (the TOTP extension is
not loaded), and you put the guac-totp-disabled attribute on the user you're
creating, Guacamole silently discards that data and does not store it in the
database (guacamole_user_attribute table). You can insert it manually into the
DB, which will then be read/honored by the system when the TOTP module is
loaded. It's worth noting this isn't limited to just that property - you could
attempt to insert any attribute, and Guacamole would discard it if an
enabled/loaded extension does not support it.
There are a couple of reasons why I'm not sure it's a great idea to allow
arbitrary data to be inserted if not supported by a module. It's possible it
would have some security implications - either by allowing someone to make use
of the fact that they know the system is being set up to insert something that
would then allow them to bypass restrictions later on (though this could
arguably be done at any time), but also just allowing for unsanitized data to
be stored in the database. I could be worrying too much on that one, it just
seems like something that you wouldn't want to generally allow.
I can think of a couple of work-arounds that might help you out. Obviously
you've already got one working by manipulating the DB directly, but here are a
couple of other ideas:
* Configure the TOTP bypass hosts
([https://guacamole.apache.org/doc/gug/totp-auth.html#bypass-enforce-totp-for-specific-hosts)]
initially, bypassing the TOTP requirement for the system being used to
configure all of the initial users, or however you want to handle that (you
could even do something like 0.0.0.0/0 for that, which should bypass it for all
hosts, though I haven't actually tested that). This should allow you to insert
those attributes, since the TOTP module would still be loaded and enabled
without actually having the TOTP enforced.
* If you have some Java code writing expertise, write and load an extension
that recognizes the guac-totp-disabled attribute, allowing that to be written
to the database for the users, but doesn't actually do any enforcement. Set
that module up to be loaded during your deployment, then disable that one and
enable the TOTP module after you're done populating the database.
Beyond that, I'll have to wait for some of the other developers to weigh in and
see what they think about whether we should allow attributes to be inserted
without a supporting module.
> API support for persisting TOTP disable attributes when TOTP is globally
> enabled
> --------------------------------------------------------------------------------
>
> Key: GUACAMOLE-2140
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-2140
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-auth-jdbc, guacamole-auth-totp
> Environment: Guacamole Version: 1.6.0
> Deployment: Docker containers with two-phase deployment
> Authentication: Database with TOTP extension
> Reporter: Tom P
> Priority: Minor
>
> h2. Summary
> Requesting API support for persisting TOTP disable attributes when TOTP is
> globally enabled, avoiding database workarounds during automated deployment.
> _Edit: clarified API behaviour after further testing._
> h2. Use Case: Automated Deployment
> Our deployment scenario requires:
> * {*}Global TOTP{*}: Enabled for all new users by default{*}{*}
> * {*}API automation user{*}: TOTP disabled for programmatic access
> * {*}Custom admin user{*}: TOTP enabled for interactive use
> This configuration enables automation workflows that cannot handle
> interactive TOTP challenges.
> h2. Current Problem
> Automated installed is done in 2 phases
> # Automated user creation with TOTP disabled attribute
> # Enabling TOTP
> When TOTP is *not globally enabled* ('Phase 1'), the REST API does not store
> TOTP disable attributes:
> {code:python}
> # This this call works during Phase 1 (TOTP not globally enabled)
> api_attributes = {"guac-totp-disabled": "true"}
> client.create_user(api_user, api_pass, api_attributes)
> client.update_user_attributes(api_user, {"guac-totp-disabled": "true"})
> {code}
> However, when TOTP is *globally enabled* ('Phase 2'), TOTP is still enabled
> for all users as the attribute was not saved
> h3. Root Cause
> API does not save TOTP user attributes when TOTP extension is not enabled.
> h2. Current Workaround
> Database manipulation is required to restore the disable attribute:
> {code:sql}
> -- Restore the disable attribute
> INSERT INTO guacamole_user_attribute (user_id, attribute_name,
> attribute_value)
> VALUES (user_id, 'guac-totp-disabled', 'true')
> ON DUPLICATE KEY UPDATE attribute_value='true';
> -- Clear forced enrolment
> DELETE FROM guacamole_user_attribute
> WHERE user_id = user_id
> AND attribute_name IN ('guac-totp-key-secret', 'guac-totp-key-confirmed');
> {code}
> h2. Proposed Improvement
> Modify the API module to save {{guac-totp-disabled}} attributes for new and
> updated users, even when global TOTP is disabled.
> h2. Benefits
> * Eliminates need for database workarounds
> * Simplifies automated deploys
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
