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

Michael Jumper reassigned GUACAMOLE-256:
----------------------------------------

    Assignee: Michael Jumper

> 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
>            Assignee: 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)

Reply via email to