guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Couchman <nick.couch...@seakr.com>
Subject Re: Connection URLs and Apache Proxy/Rewrite
Date Thu, 09 Jun 2016 04:49:08 GMT

> On Jun 8, 2016, at 19:34, Mike Jumper <mike.jumper@guac-dev.org> wrote:
> 
>> On Sat, Jun 4, 2016 at 7:36 PM, Nick Couchman <nick.couchman@seakr.com> wrote:
>> First, I want to say that Guacamole is awesome.  I've followed since the very early
days of development, and just recently dug back into the project.  It's fantastic, and I think
we have several potential areas to use it across the company - between enabling remote desktop
connectivity on tablets and ultra books, and application delivery, it is proving to be quite
useful.
> 
> Hey, Nick! Glad to see you're still around.

Thanks :-).  I've started playing with the newer versions of code In a sandbox to see if I
can wrap my ahead around helping develop it - or at least writing my own extensions for it
:-).  Some of your comments later on have helped me, I think, to figure out where to go.

> 
>> 
>> I'm running into one situation, specifically when doing application delivery, that
I could use some help with.  In this particular instance I have Guacamole set up with the
No Auth plugin, and am using it to connect to Windows-based hosts over RDP.  No credentials
are being stored, and the users must authenticate with their AD credentials to the Windows
system, so it's a pretty low-risk scenario for using No Auth.
> 
> In virtually all cases, using NoAuth is a hack and a bad idea. More on this later.

Since it's your project, I'll take your word for it...kind of...more on that later. :-)

> 
>> What I'd really like to do, however, is set up specific hostnames that redirect to
a Guacamole connection.  I'm using Apache to front the HTTP connections and using mod_proxy
to connect to Tomcat.  Let's say my server is guacamole.example.local, but that I want <application>.apps.example.local
to redirect to guacamole.example.local/guacamole/#/client/<connection id>.  I've tried
several Apache incantations to get this working, and have not stumbled across the correct
configuration.  My most recent set of configs looks like this:
>> 
>> <VirtualHost *:80>
>>         ServerName erp.apps.example.local
>>         ProxyPass / http://localhost:8080/guac/ flushpackets=on
>>         ProxyPassReverse / http://localhost:8080/guac/
>>         RewriteRule / "/#/client/SUZTIExpdmUAYwBub2F1dGg=" [NE]
>>         ProxyPassReverseCookiePath /guac /
>> </VirtualHost>
> 
> This will not work, because it is not the server that needs to read that URL; it is the
JavaScript code of the web application. It is the duty of the page handling the /#/client/...
URL to decode the base64 identifier and use it to provide the correct HTTP parameters when
making the connection request.
> 
> Even if we did not use these base64 identifiers, it is unlikely such an approach would
work for any application using these sorts of "/#/..." URLs, as everything following the hash
is handled within the browser only. You cannot rely on an HTTP client sending anything following
a hash character back to the server.

Okay, this makes sense when I think about it - I've been thinking of Guacamole as a server-side
application, since it runs in Tomcat.  Thinking of it as a client-side, JavaScript application
helps me understand this, plus some of the development stuff.

> 
> The part following the hash of a URL is known as the "fragment identifier". From the
Wikipedia page covering this[1]:
> 
> "... Clients are not supposed to send URI-fragments to servers when they retrieve a document,
and without help from a local application (see below) fragments do not participate in HTTP
redirections. ..."
> 
> BUT! All is not lost. You can do this, and you can do it without using NoAuth (the way
it should be done 99.99999% of the time, IMHO). Consider:
> 
> 1) A Guacamole extension can leverage just about anything present in an HTTP request
for the sake of authentication and authorization. You can use the content of the HTTP request
to determine what data is available to the user, ideally while validating that they are indeed
authenticated to access the system. You could use the "Host" header to determine virtual host[2]
they accessed, for example.
> 
> 2) If a user has access to only one connection, they will be taken to that connection
automatically. You won't need to include the client identifier in the URL if they only have
one connection to begin with.

So, it sounds like I need to write a Guacamole extension that looks at the virtual host accessed
and then redirects that over to a specific connection.  I'm not entirely sure I understand
the connection to the authentication mechanism, though - are you suggesting that an authentication
extension that uses Username + Password + Virtual Host would then give a user a single connection,
which would automatically connect?  Or are you suggesting writing an authentication mechanism
that doesn't even use username and password, just looks at Host header and "authenticates"
(perhaps authorizes is the right term) that way?  Either way, I guess I really do need to
brush up on my Guacamole making skills :-).

> 
> If you embrace the authentication system (GOOD!) instead of bypassing the authentication
system (BAD!), and leverage it to both provide your users with what is requested and restrict
them to only what they are allowed, you will have a better and safer system that does what
you need.

So, one of the things I'm trying to avoid here is double-authentication.  In the case of many
of the RemoteApp instances I have, I need users to authenticate to the Windows system for
the RDP session, which means I can't share common connections among users with saved credentials
(in my mind, saved credentials are bad, anyway).  So, it seems a little overly-burdensome
to require the users, who are already on a trusted network, to authenticate to Guacamole,
and then have them turn around and log in to Windows.  Which means either an authentication
mechanism that does not require username and password (which is why I've currently chosen
NoAuth), or a way to pass credentials through from the Guacamole login to the RDP session
(which would be really cool, and then AD's LDAP could be used for authentication to Guacamole
and passed on to RDP), or a way to store a user's AD credentials in Guacamole separate from
a single RDP connection, but available to any/all RDP connections.

I'm open to further discussion/suggestions on this...

> 
> - Mike "I really think we should stop supporting NoAuth" Jumper
> 

I have no personal affinity for NoAuth, it just behaves the way I want it to for the users
on my network.  Alternative routes are definitely something I will consider if NoAuth is not
the way.

-Nick

==
This e-mail may contain SEAKR Engineering (SEAKR) Confidential and Proprietary Information.
If this message is not intended for you, you are strictly prohibited from using this message,
its contents or attachments in any way. If you have received this message in error, please
delete the message from your mailbox. This e-mail may contain export-controlled material and
should be handled accordingly.
Mime
View raw message