About Authentication Token (Guacamole 1.3.0)

[rs...@krf.biglobe.ne.jp]

Hello,

LB exists between guacamole and client
Session information is currently implemented in LB.

Stop maintaining sessions(cookie) using LB,
I want to use tomcat session replication instead.

However, Guacamole does recognize that it uses tokens for authentication.

If LB randomly distributes、There is a possibility of re-login due to a mismatch of tokens.

Token information to Memcached and Redis
How do I save / recall?

Thank you.

RE: About Authentication Token (Guacamole 1.3.0)

[rs...@krf.biglobe.ne.jp]

Thank you for your reply.

 

I think it's difficult at this point.

 

I want to do my best to come up with ideas!

 

From: Nick Couchman <vn...@apache.org> 
Sent: Thursday, May 13, 2021 7:54 PM
To: user@guacamole.apache.org; rst_pi_sisk10.vi@krf.biglobe.ne.jp
Subject: Re: About Authentication Token (Guacamole 1.3.0)

 

On Thu, May 13, 2021 at 2:06 AM <rst_pi_sisk10.vi@krf.biglobe.ne.jp <ma...@krf.biglobe.ne.jp> > wrote:

Hello,

LB exists between guacamole and client
Session information is currently implemented in LB.

Stop maintaining sessions(cookie) using LB,
I want to use tomcat session replication instead.

However, Guacamole does recognize that it uses tokens for authentication.

If LB randomly distributes、There is a possibility of re-login due to a mismatch of tokens.

Token information to Memcached and Redis
How do I save / recall?

Currently Guacamole does not store session information, including tokens, in any sort of persistent or shared database, so this is not possible. In order to get this to work you would need to modify the Guacamole code such that session information was stored in a way that could be replicated across multiple Tomcat instances. Memcached and/or Redis are certain ways to do that, and Tomcat's built-in session replication might also allow for this, but not without modifications to Guacamole.

 

The easier way to do this, without code modifications, is to make sure that the load balancer persists a session to a particular Tomcat server for the life of that session (sometimes called "sticky" or "persistent" sessions). Even if you get past the login token issue and manage to replicate that information across multiple Guacamole Client instances on multiple Tomcat servers you would end up with similar issues with an active Guacamole connection - if the load balancer randomly switches a client that is connected to a remote server to a different Tomcat back-end, the Guacamole connection will drop. So, session persistence between client and Tomcat server is really a better way to go, at least until the Guacamole code is modified in such a way that it supports replication of this information.

 

If you have ideas on how to modify the Guacamole code to implement this support, feel free to open a pull request :-)!

 

-Nick

Re: About Authentication Token (Guacamole 1.3.0)

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

On Thu, May 13, 2021 at 2:06 AM <rs...@krf.biglobe.ne.jp> wrote:

> Hello,
>
> LB exists between guacamole and client
> Session information is currently implemented in LB.
>
> Stop maintaining sessions(cookie) using LB,
> I want to use tomcat session replication instead.
>
> However, Guacamole does recognize that it uses tokens for authentication.
>
> If LB randomly distributes、There is a possibility of re-login due to a
> mismatch of tokens.
>
> Token information to Memcached and Redis
> How do I save / recall?
>
Currently Guacamole does not store session information, including tokens,
in any sort of persistent or shared database, so this is not possible. In
order to get this to work you would need to modify the Guacamole code such
that session information was stored in a way that could be replicated
across multiple Tomcat instances. Memcached and/or Redis are certain ways
to do that, and Tomcat's built-in session replication might also allow for
this, but not without modifications to Guacamole.

The easier way to do this, without code modifications, is to make sure that
the load balancer persists a session to a particular Tomcat server for the
life of that session (sometimes called "sticky" or "persistent" sessions).
Even if you get past the login token issue and manage to replicate that
information across multiple Guacamole Client instances on multiple Tomcat
servers you would end up with similar issues with an active Guacamole
connection - if the load balancer randomly switches a client that is
connected to a remote server to a different Tomcat back-end, the Guacamole
connection will drop. So, session persistence between client and Tomcat
server is really a better way to go, at least until the Guacamole code is
modified in such a way that it supports replication of this information.

If you have ideas on how to modify the Guacamole code to implement this
support, feel free to open a pull request :-)!

-Nick

>