1.0.0 LocalStorage auth instead of cookies

[Lev Dubinets <le...@live.com>]

Hi,

Prior to 1.0.0 I had a reverse proxy in front of Guacamole that modified the GUAC_AUTH cookie paths so that I could have two browser windows open with two different Guacamole sessions (one at domain .com/username1 and other at domain .com/username2).

With 1.0.0 and the LocalStorage changes theres no way to "path" the entries at all. What are some recommended solutions for this? Is it possible to write some kind of auth plugin to use cookies instead of localstorage?

Thanks,
Lev

Re: 1.0.0 LocalStorage auth instead of cookies

[Mike Jumper <mj...@apache.org>]

On Mon, Mar 4, 2019 at 7:49 PM Lev Dubinets <le...@live.com> wrote:

> To add to that, I'd bet that most serious deployments of guacamole are
> putting it behind nginx or some other proxy and/or load balancer.
>

Yes, though it's mainly guacd that needs the most balancing.

The cookies allow the backend to control and isolate guacamole sessions or
> deployments. This is really useful. For large-scale deployments this has to
> be a must-have feature.
>

No. With respect to routing of sticky sessions, the typical case would
involve configuring the balancer to set its own cookie independent of the
backend session.

Setting an HTTP header specifically for use by balancers (such that they
can properly route future requests based on the "token" parameter) might be
a good way to expand this case. Additionally setting and accepting a cookie
as an optional alternative to the "token" parameter might also be worth
doing. It's definitely not a requirement for a deployment to be
large/serious.

- Mike

Re: 1.0.0 LocalStorage auth instead of cookies

[Lev Dubinets <le...@live.com>]

To add to that, I'd bet that most serious deployments of guacamole are putting it behind nginx or some other proxy and/or load balancer. The cookies allow the backend to control and isolate guacamole sessions or deployments. This is really useful. For large-scale deployments this has to be a must-have feature. The vulnerability is an interesting point, I had actually noticed that the Secure flag was missing too and was adding it manually with an nginx rule. It is not an inherent flaw of cookies though. The rest of the world wide web does cookie-based authentication for a reason. Storing everything in localstorage means that the backend has no control.

Lee, since you're having this same problem, I can share my stop gap solution. LocalStorage is isolated based on SameOrigin policy, so https://a.example.com and https://b.example.com don't share LocalStorage. If you are able to issue wildcard https certs (LetsEncrypt can do it) and configure your nginx/proxy to match locations with an appropriate regex, then you can achieve session isolation with subdomains.

I would really appreciate if a prefixing/pathing solution was defined for the LocalStorage entries though because subdomains are not always possible to use.
________________________________
From: Lee <ld...@vt.edu>
Sent: Monday, March 4, 2019 4:04 PM
To: user@guacamole.apache.org
Subject: Re: 1.0.0 LocalStorage auth instead of cookies

My issue (and need for Cookie-based auth or an alternative) is very similar.
Lev noted this in my own thread and pointed here.

In my case, we determined that our users only needed the servers for a few
hours and different times of the week or month so we generally have the
virtual machines off. We also determined that Guacamole probably not the
best system to control spinning up or down these virtual machines --
designing the extensions would have been difficult, and prone to issues as
guacamole matured. So we designed a wrapper that is responsible for ensuring
the servers are available when the users need them; The users start the
system outside guacamole, and get a button that opens a new tab with a
one-time-use cookie that drops them directly into the specified server on
demand.

To reduce any confusion, we strip away most of the guacamole client features
like user management, and let guacamole handle the RDP/SSH sessions through
'just-in-time' configurations provided by our authentication extension,
which can also pass in configuration options. Guacamole effectively persists
nothing outside sessions.

The clearing of cookies in the past caused no issues on existing sessions,
so a user could have 4 tabs with different RDP/SSH sessions at the same time
(or, in some cases, sessions to the same server that was configured to give
new SSH/RDP sessions for each connection). We found this very valuable --
such as teachers looking at or troubleshooting multiple student sessions at
the same time. It's also helpful when working on an exercise that has two
computers talking to each other. With out testing and approach, these
sessions could go on nearly indefinitely, even if their cookies were
destroyed. Survival through a tab refresh is not a requirement for us.

Incognito mode is a good work-around for technical people, but not a great
workaround for elementary and middle school students (or teachers) who are
using the guacamole service in their "Introduction to computers" class.

Does this give a possible use case for cookie-based authentication?

My team's plan is to destroy the local storage data as well as the cookies
and see if that allows us to move forward. Hopefully it allows sessions to
persist like it has in the past.

-Lee
Virginia Tech / Virginia Cyber Range



--
Sent from: https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-guacamole-general-user-mailing-list.2363388.n4.nabble.com%2F&amp;data=02%7C01%7C%7C2d8c819cccb34059bbb408d6a0fe1cf6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636873410591514300&amp;sdata=WCelKE6X8yyDl2FZaBv%2Bk0F1IaZIAgLUinDjF%2FgKkUs%3D&amp;reserved=0

Re: 1.0.0 LocalStorage auth instead of cookies

[Lee <ld...@vt.edu>]

My issue (and need for Cookie-based auth or an alternative) is very similar.
Lev noted this in my own thread and pointed here.

In my case, we determined that our users only needed the servers for a few
hours and different times of the week or month so we generally have the
virtual machines off. We also determined that Guacamole probably not the
best system to control spinning up or down these virtual machines --
designing the extensions would have been difficult, and prone to issues as
guacamole matured. So we designed a wrapper that is responsible for ensuring
the servers are available when the users need them; The users start the
system outside guacamole, and get a button that opens a new tab with a
one-time-use cookie that drops them directly into the specified server on
demand.

To reduce any confusion, we strip away most of the guacamole client features
like user management, and let guacamole handle the RDP/SSH sessions through
'just-in-time' configurations provided by our authentication extension,
which can also pass in configuration options. Guacamole effectively persists
nothing outside sessions.

The clearing of cookies in the past caused no issues on existing sessions,
so a user could have 4 tabs with different RDP/SSH sessions at the same time
(or, in some cases, sessions to the same server that was configured to give
new SSH/RDP sessions for each connection). We found this very valuable --
such as teachers looking at or troubleshooting multiple student sessions at
the same time. It's also helpful when working on an exercise that has two
computers talking to each other. With out testing and approach, these
sessions could go on nearly indefinitely, even if their cookies were
destroyed. Survival through a tab refresh is not a requirement for us.

Incognito mode is a good work-around for technical people, but not a great
workaround for elementary and middle school students (or teachers) who are
using the guacamole service in their "Introduction to computers" class.

Does this give a possible use case for cookie-based authentication?

My team's plan is to destroy the local storage data as well as the cookies
and see if that allows us to move forward. Hopefully it allows sessions to
persist like it has in the past.

-Lee
Virginia Tech / Virginia Cyber Range



--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

Re: 1.0.0 LocalStorage auth instead of cookies

[Nick Couchman <vn...@apache.org>]

On Sun, Mar 3, 2019 at 12:40 AM Lev Dubinets <le...@live.com> wrote:

> Hi,
>
> Prior to 1.0.0 I had a reverse proxy in front of Guacamole that modified
> the GUAC_AUTH cookie paths so that I could have two browser windows open
> with two different Guacamole sessions (one at domain .com/username1 and
> other at domain .com/username2).
>
> With 1.0.0 and the LocalStorage changes theres no way to "path" the
> entries at all. What are some recommended solutions for this? Is it
> possible to write some kind of auth plugin to use cookies instead of
> localstorage?
>

I don't think this would work, no - you could write an authentication
extension that would authenticate with cookies, yes, but I don't think this
would solve the issue you're seeing, because, once logged in, Guacamole
would still issue a token based on the LocalStorage method of storing data
within the browser, which would likely circumvent your cookie-based
authentication.

What is it that you're trying to accomplish, in the end?  Why do you
need/want two different sessions under two different accounts?  On the rare
occasions that I require this, I usually end up using Chrome's Incognito
mode for the second session, but I wouldn't consider my usage routine, so I
can understand that there might be situations that don't lend themselves
quite as easily to that.

-Nick

>