You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@guacamole.apache.org by "Sandro (Jira)" <ji...@apache.org> on 2023/06/19 06:37:00 UTC

[jira] [Commented] (GUACAMOLE-1659) Add HTTP Reverse Proxy Functionality

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

Sandro commented on GUACAMOLE-1659:
-----------------------------------

In addition to the desired HTTP(S) proxy function, we have one more requirement.

We are currently being asked again and again in digitization projects whether we can also add HTTP(S) web visualizations with Guacamole and whether there is also a possibility to record this access as with VNC and RDP.

> Add HTTP Reverse Proxy Functionality
> ------------------------------------
>
>                 Key: GUACAMOLE-1659
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-1659
>             Project: Guacamole
>          Issue Type: New Feature
>          Components: guacamole, guacamole-client, guacamole-server, Website
>            Reporter: Jason Mac
>            Priority: Minor
>              Labels: features
>
> Guacamole being a "Proxy" of sorts to allow the management of internal services and devices, its a reasonable jump to compare it directly to a "Jump Host".
> Currently, if one were to utilize Guacamole as a privileged access manager to all internal services, one would have to setup and manager a separate HTTP reverse proxy in order to authenticate, log, and monitor user access to management *web* interfaces. If there are dozens, maybe even hundreds of management interfaces that must be mediated then the use of a reverse proxy becomes cumbersome. Plus, a reverse proxy isn't really designed as a management mediating tool, so naturally it is not optimized for such a workflow.
> An alternative would be yet another Jump Host that has a full desktop and browser to then connect to the web management interfaces. This would be even more excessive than a reverse proxy installed along side Guacamole.
> Additionally, with the need to have full mediation of management activities, the use of 2 services or even 2+ devices, one for web management access, and the other for all other services (Guac), is not only unnecessarily complex, but also more work for users that need to SSH into backend servers and also visit corresponding web management interfaces, as an example. This also complicates the implementation of federated authentication, as now the authentication must be setup of the reverse proxy (and the numerous backend hosts) and Guacamole.
> The user interface could be very similar to all the other protocols, where there is a specific connection profile made to connect into some backend host. It could have much of the options as any reverse proxy, backend connection IP/Port, protocol, hostname, authentication headers, ect. This could provide a single pane of mediated management to users without the need for full management desktops or complex reverse proxies. 
>  
> *I think it would be extremely useful to integrate a HTTP reverse proxy into Guacamole with the easy connection, logging, monitoring, and UI that Guacamole provides.* 
>  
> Just some background of what led me to this:
> I have a Jump Host that mediates all connections between VPN users and the management of various network services. Much of those management interfaces are web based (web apps are the future...). Deploying Guacamole was a no-brainer for SSH and RDP access, but in order to monitor and log VPN client connections to these web management interfaces, I had to come up with a solution. Unfortunately that solution was an NGINX reverse proxy with about 30 server blocks for various sub-domains pointing to the various backend web management interfaces. Add to my frustration, setting up Authelia for authentication was a pain with all those server blocks. So then I thought to myself... why shouldn't Guacamole also handle this? 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)