[jira] [Commented] (GUACAMOLE-256) Deprecate the NoAuth extension

["Dmitry Katsubo (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GUACAMOLE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16794482#comment-16794482 ] 

Dmitry Katsubo commented on GUACAMOLE-256:
------------------------------------------

I do not completely agree with the statement in description that mentioned logic / steps are flawed. It could happen that Guacamole / Tomcat is running behind HTTP server like Apache / Ngnix server which acts as a reverse proxy and performs the user's authentication. In this scenario Guacamole should be able to be passed a "flag" that external authentication was performed. For example [Reverse Proxy Auth Plugin|https://wiki.jenkins.io/display/JENKINS/Reverse+Proxy+Auth+Plugin#ReverseProxyAuthPlugin-ApacheConfigurationExample] for Jenkins checks the presence of {{X-Forwarded-User}} HTTP header which is set by Apache.

Indeed above is not enough to ensure the proper authentication, in particular Tomcat should assure that it is talking to a trusted client. This can be done by either adding IP firewall rules (so that Tomcat accepts connections from Apache only) and/or forcing HTTPS certificate validation ([{{SSLProxyMachineCertificateFile}}|https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslproxymachinecertificatefile] on Apache side + [{{<Connector port="8443" truststoreFile="..." clientAuth="true" ... />}}|https://stackoverflow.com/a/11578727/267197] on Tomcat side).

With above configuration additional authentication by Guacamole is not necessary (at least I don't see where it is flawed), hence there is a need in some sort of "NoAuth" plugin.

> Deprecate the NoAuth extension
> ------------------------------
>
>                 Key: GUACAMOLE-256
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-256
>             Project: Guacamole
>          Issue Type: Improvement
>          Components: Documentation, guacamole-auth-noauth
>            Reporter: Michael Jumper
>            Assignee: Michael Jumper
>            Priority: Critical
>             Fix For: 0.9.13-incubating
>
>
> 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
(v7.6.3#76005)