Michael Jumper created GUACAMOLE-256:
----------------------------------------
Summary: The NoAuth extension exists
Key: GUACAMOLE-256
URL: https://issues.apache.org/jira/browse/GUACAMOLE-256
Project: Guacamole
Issue Type: Bug
Components: Documentation, guacamole-auth-noauth
Reporter: Michael Jumper
Priority: Critical
The NoAuth extension has been a consistent source of issues for both users and
the Guacamole development community. It's main downstream use has proven to be
a quick-and-dirty hack for integrating Guacamole into an external application,
disabling the authentication system rather than writing an extension to truly
integrate the systems together. Over the years, simply using NoAuth has become
bad practice.
The general thought process surrounding a NoAuth use case tends to be as
follows:
# I wish to integrate Guacamole into my application.
# My application prompts the user for their username and password.
# If I link to Guacamole within my application, users will be prompted for
their username and password again.
# Things would be so much easier if Guacamole didn't prompt for
username/password at all.
# I will disable Guacamole's authentication system.
This logic is flawed. If an external application validates a user's username
and password, and that application will link to Guacamole, that doesn't mean
that Guacamole is protected by that username and password. As long as the
systems are independent, "disabling" Guacamole's authentication ensures that
part of the deployment is completely unprotected.
If Guacamole is to be integrated within an external application, then the
systems must be linked such that the user's access is verified at all levels,
including within Guacamole. There is simply no way around this.
It's time NoAuth was removed as an officially-supported option. Downstream
integrations of Guacamole should use the extension API, as intended by design,
or the core Guacamole API for absolute low-level control.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
