> On Jun 8, 2016, at 19:34, Mike Jumper <[email protected]> wrote: > >> On Sat, Jun 4, 2016 at 7:36 PM, Nick Couchman <[email protected]> >> 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.
