You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by ggagnon <gg...@ciena.com> on 2018/03/21 19:47:43 UTC
In-Context Launch and Caching
Trying to setup Guacamole to support the invocation of connections in-context
(target node as URL parameter). I've set up my own authentication plugin
as per documentation (based on SimpleAuthenticationProvider) and I'm
successfully activating it as part of the docker container.
That plugin simply validates the user (against our own store) and returns a
new Connection configuration for the given parameter (again, using
information from our own store). [i.e. the only active plugin is ours,
user/connection data is not in files/mysql).
No username/password is provided with the connection configuration (the user
needs to log into the target explicitly) and that's OK for now. The
connection configuration only gets the IP, Port, and Protocol information.
The problem I'm having is that when I test/invoke the URL for, say, node X
in a browser (Chrome), I get my terminal window for node X. However, if I
then do the same for node Y, I still get the terminal connecting to node X.
It's not clear at all where the issue lies.
There's some signs of browser caching problems but I'm not convinced (the
Chrome Dev/Network tool does seem to show that the Y URL is sent down but it
gets muddled through the redirections...)
On the server logs, the puzzling thing is that on the second call, I see no
trace of my authentication plugin being invoked at all. Instead, the logs
show that the user is just immediately connected to the previous target...
18:57:18.014 [http-nio-8080-exec-4] INFO o.a.g.environment.LocalEnvironment
- GUACAMOLE_HOME is "/root/.guacamole".
18:57:18.057 [http-nio-8080-exec-4] INFO o.a.g.tunnel.TunnelRequestService
- User "f9cf9ef2-670f-4801-b78c-3b49a2162a35" connected to connection "X".
How can I get all requests to be vetted through the my plugin'
getAuthorizedConfigurations(Credentials)?
It's as if there is some caching and I thought that overriding some
additional calls like authenticateUser might do the work but it's not
obvious with many needed bits in SimpleAuthenticationProvider (like
SimpleAuthenticatedUser) being defined as private...
Thanks for any help.
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
Re: In-Context Launch and Caching
Posted by Nick Couchman <vn...@apache.org>.
>
> I don't think the logout will work for me as I have to hide all general
> aspects of Guacamole (no home page, etc... ) to get the launch-in context.
> I have put a trace in the shutdown() method but I'm not seeing it being
> called (probably a side effect of the previous).
> I'm happy to hear of the periodic clean up, I think/hope that will settle
> my
> worry.
>
>
It's probably only called on Logout, or when the DELETE method is called on
the api/tokens endpoint, so you'll have to do something with that in order
to get it to run. You also could do something like override the tunnel
connection methods in the Connection class and do something to make the
credentials invalid as soon as the tunnel is connected such that someone
can't reuse it. Depends on how concerned you are about someone being able
to maliciously (re)use the credentials.
> Had to play some interesting games (comparing the new request to the
> existing configuration of the user) to avoid re-authenticating uselessly as
> updateAuthenticatedUser is called more often than expected but I think I
> have it working now so I can serve a new authorization every time a new
> target is invoked (within the same session or not).
>
You might take a look at these methods in some of the other modules, like
the CAS, Duo, and Header ones, as they may behave similarly to how you're
attempting to get your module to work.
>
> My next challenge now is to figure out a way to display a proper error
> message when the authorization fails (there is no cascading to other
> authorization plugin and none will do). Right now, all I get is a blank
> page.
>
Again, might look at some of the other modules to get examples - throwing a
GuacamoleInvalidCredentialsException or
GuacamoleInsufficientCredentialsException should allow you to display a
custom page (Form/Field) that gives the user a userful error message, or
redirect the user to some other page for authentication (CAS, OAuth, Duo do
this).
-Nick
Re: In-Context Launch and Caching
Posted by ggagnon <gg...@ciena.com>.
Thanks for the info.
I don't think the logout will work for me as I have to hide all general
aspects of Guacamole (no home page, etc... ) to get the launch-in context.
I have put a trace in the shutdown() method but I'm not seeing it being
called (probably a side effect of the previous).
I'm happy to hear of the periodic clean up, I think/hope that will settle my
worry.
Had to play some interesting games (comparing the new request to the
existing configuration of the user) to avoid re-authenticating uselessly as
updateAuthenticatedUser is called more often than expected but I think I
have it working now so I can serve a new authorization every time a new
target is invoked (within the same session or not).
My next challenge now is to figure out a way to display a proper error
message when the authorization fails (there is no cascading to other
authorization plugin and none will do). Right now, all I get is a blank
page.
Thanks
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
Re: In-Context Launch and Caching
Posted by Nick Couchman <vn...@apache.org>.
>
> As for the memory/accumulation issue I raise, in
> AuthenticationService.authenticate, I see that tokenSessionMap is
> populated
> with information for each session. However, it's not clear when those are
> removed from the map. I think I deduce from a rest API call
> (Administration?) And there's another case upon an unclear exception but
> there's limits to how IntelliJ will let me traceback and reverse engineer
> this...
>
>
A couple of things, here:
- There is code during the "logout" process that tears down the session
(look at the DELETE method on the api/tokens endpoint).
- In your custom authentication module, there's a shutdown() method that
you could use to clean up anything specific to your authentication module.
- If you put Guacamole into DEBUG logging and look at the Tomcat logs
(catalina,out or syslog, depending on your configuration) you'll see
periodic messages from o.a.g.rest.auth.HashTokenSessionMap cleaning up old
sessions.
- I believe Tomcat's monitoring/management interface can show you memory
utilization for a deployed application, so you can monitor that and make
sure it isn't leaking.
-Nick
Re: In-Context Launch and Caching
Posted by ggagnon <gg...@ciena.com>.
Actually, I may have just found a way I think...
In my auth provider (derived from SimpleAuthenticationProvider), I just
overrode updateAuthenticatedUser() and updateUserContext(). The Simple
class' implementation simply returns the same user and context, mine force
the re-authentication:
public AuthenticatedUser updateAuthenticatedUser(AuthenticatedUser
authenticatedUser,
Credentials
credentials) throws GuacamoleException {
return authenticateUser(credentials);
}
public UserContext updateUserContext(UserContext context,
AuthenticatedUser authorizedUser, Credentials credentials) throws
GuacamoleException {
return getUserContext(authorizedUser);
}
However now, earch URL results in 2/3 runs at my authentication
(getAuthorizedConfigurations ) as the update calls seem to be invoked after
the valid calls:
The first time around for a user:
getAuthorizedConfigurations
-> updateAuthenticatedUser (-> getAuthorizedConfigurations)
-> updateUserContext (really does nothing)
and on subsequent calles whilst the cookie is there:
updateAuthenticatedUser (-> getAuthorizedConfiguration)
-> updateUserContext (->
updateAuthenticatedUser
->
getAuthorizedConfigurations
->
updateUserContext)
nearly recursive, but not quite... The end result is ok, I get 2 different
connections to the 2 different targets, however, I need to figure out how to
safely avoid these redundant calls...
As for the memory/accumulation issue I raise, in
AuthenticationService.authenticate, I see that tokenSessionMap is populated
with information for each session. However, it's not clear when those are
removed from the map. I think I deduce from a rest API call
(Administration?) And there's another case upon an unclear exception but
there's limits to how IntelliJ will let me traceback and reverse engineer
this...
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
Re: In-Context Launch and Caching
Posted by Nick Couchman <vn...@apache.org>.
I believe I also remember someone mentioning that the GUAC_TOKEN cookie
might be part of this. Maybe blocking/deleting that cooking would help?
-Nick
On Thu, Mar 22, 2018 at 8:06 AM, Joachim Lindenberg <jo...@lindenberg.one>
wrote:
> I had a similar issue in my extension and had to disable http caching in
> java for the URL I used to do authentication and obtain configuration
> information.
> Maybe you are hit by a similar issue.
> Best Regards,
> Joachim
>
> -----Original Message-----
> From: ggagnon [mailto:ggagnon@ciena.com]
> Sent: Mittwoch, 21. März 2018 20:48
> To: user@guacamole.apache.org
> Subject: In-Context Launch and Caching
>
>
> Trying to setup Guacamole to support the invocation of connections
> in-context
> (target node as URL parameter). I've set up my own authentication plugin
> as per documentation (based on SimpleAuthenticationProvider) and I'm
> successfully activating it as part of the docker container.
> That plugin simply validates the user (against our own store) and returns a
> new Connection configuration for the given parameter (again, using
> information from our own store). [i.e. the only active plugin is ours,
> user/connection data is not in files/mysql).
> No username/password is provided with the connection configuration (the
> user
> needs to log into the target explicitly) and that's OK for now. The
> connection configuration only gets the IP, Port, and Protocol information.
>
> The problem I'm having is that when I test/invoke the URL for, say, node X
> in a browser (Chrome), I get my terminal window for node X. However, if I
> then do the same for node Y, I still get the terminal connecting to node X.
>
> It's not clear at all where the issue lies.
> There's some signs of browser caching problems but I'm not convinced (the
> Chrome Dev/Network tool does seem to show that the Y URL is sent down but
> it
> gets muddled through the redirections...)
> On the server logs, the puzzling thing is that on the second call, I see no
> trace of my authentication plugin being invoked at all. Instead, the logs
> show that the user is just immediately connected to the previous target...
>
> 18:57:18.014 [http-nio-8080-exec-4] INFO o.a.g.environment.
> LocalEnvironment
> - GUACAMOLE_HOME is "/root/.guacamole".
> 18:57:18.057 [http-nio-8080-exec-4] INFO o.a.g.tunnel.
> TunnelRequestService
> - User "f9cf9ef2-670f-4801-b78c-3b49a2162a35" connected to connection "X".
>
> How can I get all requests to be vetted through the my plugin'
> getAuthorizedConfigurations(Credentials)?
> It's as if there is some caching and I thought that overriding some
> additional calls like authenticateUser might do the work but it's not
> obvious with many needed bits in SimpleAuthenticationProvider (like
> SimpleAuthenticatedUser) being defined as private...
>
> Thanks for any help.
>
>
>
>
>
> --
> Sent from:
> http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
>
>
>
Re: In-Context Launch and Caching
Posted by Nick Couchman <vn...@apache.org>.
On Thu, Mar 22, 2018 at 8:56 AM, ggagnon <gg...@ciena.com> wrote:
> Actually, as I keep investigating, it seems the issue is in good parts
> "caused" by the GUAC_AUTH cookie. If I delete that cookie between
> invocations, all URL calls seem to be really authenticated.
>
Haha, replied just as this one came in. Yes, GUAC_AUTH, not GUAC_TOKEN.
> Now to find a way to work around that cookie use/creation (or invalidate
> it).
> The cause, I believe, is that in order to get the terminal session started
> immediately, I have to create an on-the-fly user authorization with only
> one
> connection allowed (to be different for each invocation). Looks like
> that's a border case for Guacamole. If there are multiple connections,
> then there is a home page to pick from (which we precisely want to avoid to
> obtain true in-context launch) so authentication caching through the cookie
> is OK.
>
I'm not sure if this is the best way to do, Mike might have some
suggestions, but part of your extension can include HTML/JS code, so maybe
you could write code as part of your extension that clears that cookie out.
> I also see signs that some information is kept by the server for these
> sessions so I now also worry about the accumulation of them (memory) over
> time.
>
>
What kind of information are you talking about?
-Nick
RE: In-Context Launch and Caching
Posted by ggagnon <gg...@ciena.com>.
Actually, as I keep investigating, it seems the issue is in good parts
"caused" by the GUAC_AUTH cookie. If I delete that cookie between
invocations, all URL calls seem to be really authenticated.
Now to find a way to work around that cookie use/creation (or invalidate
it).
The cause, I believe, is that in order to get the terminal session started
immediately, I have to create an on-the-fly user authorization with only one
connection allowed (to be different for each invocation). Looks like
that's a border case for Guacamole. If there are multiple connections,
then there is a home page to pick from (which we precisely want to avoid to
obtain true in-context launch) so authentication caching through the cookie
is OK.
I also see signs that some information is kept by the server for these
sessions so I now also worry about the accumulation of them (memory) over
time.
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
RE: In-Context Launch and Caching
Posted by Joachim Lindenberg <jo...@lindenberg.one>.
I had a similar issue in my extension and had to disable http caching in
java for the URL I used to do authentication and obtain configuration
information.
Maybe you are hit by a similar issue.
Best Regards,
Joachim
-----Original Message-----
From: ggagnon [mailto:ggagnon@ciena.com]
Sent: Mittwoch, 21. März 2018 20:48
To: user@guacamole.apache.org
Subject: In-Context Launch and Caching
Trying to setup Guacamole to support the invocation of connections
in-context
(target node as URL parameter). I've set up my own authentication plugin
as per documentation (based on SimpleAuthenticationProvider) and I'm
successfully activating it as part of the docker container.
That plugin simply validates the user (against our own store) and returns a
new Connection configuration for the given parameter (again, using
information from our own store). [i.e. the only active plugin is ours,
user/connection data is not in files/mysql).
No username/password is provided with the connection configuration (the user
needs to log into the target explicitly) and that's OK for now. The
connection configuration only gets the IP, Port, and Protocol information.
The problem I'm having is that when I test/invoke the URL for, say, node X
in a browser (Chrome), I get my terminal window for node X. However, if I
then do the same for node Y, I still get the terminal connecting to node X.
It's not clear at all where the issue lies.
There's some signs of browser caching problems but I'm not convinced (the
Chrome Dev/Network tool does seem to show that the Y URL is sent down but it
gets muddled through the redirections...)
On the server logs, the puzzling thing is that on the second call, I see no
trace of my authentication plugin being invoked at all. Instead, the logs
show that the user is just immediately connected to the previous target...
18:57:18.014 [http-nio-8080-exec-4] INFO o.a.g.environment.LocalEnvironment
- GUACAMOLE_HOME is "/root/.guacamole".
18:57:18.057 [http-nio-8080-exec-4] INFO o.a.g.tunnel.TunnelRequestService
- User "f9cf9ef2-670f-4801-b78c-3b49a2162a35" connected to connection "X".
How can I get all requests to be vetted through the my plugin'
getAuthorizedConfigurations(Credentials)?
It's as if there is some caching and I thought that overriding some
additional calls like authenticateUser might do the work but it's not
obvious with many needed bits in SimpleAuthenticationProvider (like
SimpleAuthenticatedUser) being defined as private...
Thanks for any help.
--
Sent from:
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/