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

["Michael Jumper (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GUACAMOLE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Jumper resolved GUACAMOLE-256.
--------------------------------------
       Resolution: Fixed
    Fix Version/s: 0.9.13-incubating

> 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
(v6.3.15#6346)