You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by Lee <ld...@vt.edu> on 2019/02/27 23:06:11 UTC
Authentication Changes in 1.0.0
Hello,
I'm seeing a change in behavior I'm not sure how to work around. I'm using
the docker image guacamole/guacamole:1.0.0 with a custom authentication
provider extending SimpleAuthenticationProvider. With guacamole 0.9.14, I
saw calls to getAuthorizedConfigurations in the authentication provider with
every user request. This was great, as it allowed a single user to have
multiple sessions open in separate tabs as the function could return
different hosts/protocols/usernames/passwords.
Now on 1.0.0, it seems to ignore the authentication provider if they've
already passed through once (even through the passed in credentials object
would result in a different configuration). This pass through then tries to
re-connect to the previously used host with old username/password. This is
not our desired functionality and seems to persist for quite some time. I'm
unsure how to restore the previous functionality as long as it completely
bypasses the extension when the follow up request comes in.
Any guidance to documentation or comments on what the culprit might be would
be helpful.
-Lee
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
Re: Authentication Changes in 1.0.0
Posted by Nick Couchman <vn...@apache.org>.
On Mon, Mar 4, 2019 at 7:16 PM Lee <ld...@vt.edu> wrote:
> Mike, thank you for your feedback. I've forwarded that onto my teammates to
> look into. I agree, I'd prefer to not go in a route that is going to be
> constantly against the design of Guacamole, and the links you provide might
> be a great alternative I did not see while looking at the
> SimpleAuthenticationProvider code. If that ANONYMOUS_IDENTIFIER pathway
> allows a second session without re-using the existing one, that would
> probably be a perfect work-around to the problem. If that isn't quite
> right,
> I'll explore the extension API options.
>
>
Based on what you've said in your other thread, it does sound like you're
fighting the interface rather than working with it :-).
One thing that is worth noting is that Guacamole does create persistent
URLs for connections within the interface - so, when you see something like:
https://guacamole.example.com/guacamole/#/client/MzkAYwBwb3N0Z3Jlc3Fs
The end part of it (/client/MzkAYwBwb3N0Z3Jlc3Fs) will always take you to
the same connection, because it encodes the connection type (connection or
connection group), the data source name, and the identifier, within that
identifier. So, one idea would be to create links to these connections (on
a home page or separate page somewhere) and then use some sort of SSO
extension (CAS, OpenID, maybe Header) to log users in so that they could
transparently open those connections. The connections could be stored in
the JDBC module, stacked with a SSO module, so that permissions could be
assigned within JDBC but still transparently log users in.
Another idea would be to use the common Guacamole pieces (guacd,
guacamole-common and guacamole-common-js) and build your own web
application around the protocol and common components rather than trying to
squeeze the full Guacamole Client into your environment, if it doesn't fit.
-Nick
Re: Authentication Changes in 1.0.0
Posted by Lee <ld...@vt.edu>.
Mike, thank you for your feedback. I've forwarded that onto my teammates to
look into. I agree, I'd prefer to not go in a route that is going to be
constantly against the design of Guacamole, and the links you provide might
be a great alternative I did not see while looking at the
SimpleAuthenticationProvider code. If that ANONYMOUS_IDENTIFIER pathway
allows a second session without re-using the existing one, that would
probably be a perfect work-around to the problem. If that isn't quite right,
I'll explore the extension API options.
Thanks
-Lee
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
Re: Authentication Changes in 1.0.0
Posted by Mike Jumper <mj...@apache.org>.
On Mon, Mar 4, 2019 at 2:32 PM Lee <ld...@vt.edu> wrote:
> Thanks Nick and Mike.
>
> The change ended up being on the front end & connection to the
> authentication module. We were destroying the users cookie if they tried to
> re-connect. With the changes to have that information in local storage,
> that
> broke our authentication process before it started. I suppose we'll have to
> see if deleting the local storage objects as well now will work.
I wouldn't recommend destroying local storage objects as a means of
achieving this. You old solution (destroying the user's cookie) is built
upon a workaround which actively fights the internals of the webapp, and so
will be brittle. You should instead look to a solution which is built upon
(not against) what's provided.
The extension API allows for user data to be derived dynamically (see
previous emails in this thread), including based on changes to the request
like the cookie that your system generates. I recommend leveraging that
aspect of the API to achieve what it's designed to do.
You might additionally look into using the anonymous username for your
users on the Guacamole side:
http://guacamole.apache.org/doc/guacamole-ext/org/apache/guacamole/net/auth/AuthenticatedUser.html#ANONYMOUS_IDENTIFIER
The anonymous user has different semantics and will not persist the auth
token:
https://github.com/apache/guacamole-client/blob/5ce0c0f0358096d87e19c7decdb4d6dfd21aeff5/guacamole/src/main/webapp/app/auth/service/authenticationService.js#L118-L120
- Mike
Re: Authentication Changes in 1.0.0
Posted by Mike Jumper <mj...@apache.org>.
On Mon, Mar 4, 2019 at 3:15 PM Lev Dubinets <le...@live.com> wrote:
> Hi Lee, I actually have the same/similar issue and started a thread about
> this recently:
> http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/1-0-0-LocalStorage-auth-instead-of-cookies-tp4996.html
> .
>
> Probably best to merge my thread into yours.
>
> Nick/Mike, can you elaborate why this change was made?
>
https://issues.apache.org/jira/browse/GUACAMOLE-549
> What was wrong with cookie-based authentication?
>
Nothing is inherently wrong with cookie-based authentication. Apache
Guacamole does not use cookies, and actually hasn't since it migrated to an
interface driven by REST services. The 1.0.0 changes were to migrate
client-side storage of the session token from a cookie to local storage.
Storing the session token within a cookie is problematic given that the
cookie is not actually read by the server. It unnecessarily exposes the
contents of the cookie when all relevant endpoints are actually expecting
to receive the token only via a "token" query parameter in each request.
The unnecessary use of a cookie was partly the cause of a vulnerability
addressed by 1.0.0:
http://mail-archives.apache.org/mod_mbox/guacamole-announce/201901.mbox/%3CCALKeL-O%2B%3DRxbd0y%2BhSB9%3DY0N400A8sV2BiKgZfNsjGxZipA-uQ%40mail.gmail.com%3E
> Re: Nick's questions "What are you trying to accomplish?": I have software
> written that allows people to connect to multiple servers. 1.0.0
> unfortunately breaks it.. Having different accounts is useful for
> segregation as well as for being able to automatically open the single
> session in the account.
>
Nothing in 1.0.0 will prevent you from having different accounts, nor with
connecting to multiple servers. You won't be able to sign in as multiple
users to the same domain from within the same browser, but assuming your
users don't all share the same browser instance things will still work as
expected.
It might be a good idea for the new local storage of the token to be
modified to be path-specific, allowing multiple deployments below the same
domain, but migrating back to cookies is not the way to go.
- Mike
Re: Authentication Changes in 1.0.0
Posted by Lev Dubinets <le...@live.com>.
Hi Lee, I actually have the same/similar issue and started a thread about this recently: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/1-0-0-LocalStorage-auth-instead-of-cookies-tp4996.html.
Probably best to merge my thread into yours.
Nick/Mike, can you elaborate why this change was made? What was wrong with cookie-based authentication?
Re: Nick's questions "What are you trying to accomplish?": I have software written that allows people to connect to multiple servers. 1.0.0 unfortunately breaks it.. Having different accounts is useful for segregation as well as for being able to automatically open the single session in the account.
________________________________
From: Lee <ld...@vt.edu>
Sent: Monday, March 4, 2019 2:32 PM
To: user@guacamole.apache.org
Subject: Re: Authentication Changes in 1.0.0
Thanks Nick and Mike.
The change ended up being on the front end & connection to the
authentication module. We were destroying the users cookie if they tried to
re-connect. With the changes to have that information in local storage, that
broke our authentication process before it started. I suppose we'll have to
see if deleting the local storage objects as well now will work.
I just wanted to follow up in case someone found this thread and had a
similar issue with an update from an older version to the new version that
doesn't rely on cookies existence.
--
Sent from: https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-guacamole-general-user-mailing-list.2363388.n4.nabble.com%2F&data=02%7C01%7C%7Cd7768f242b244885505508d6a0f15188%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636873355639043785&sdata=qSlYvrtCon6KYN%2FrmGT1kJarLIysNvTFpAX9nhtjokk%3D&reserved=0
Re: Authentication Changes in 1.0.0
Posted by Lee <ld...@vt.edu>.
Thanks Nick and Mike.
The change ended up being on the front end & connection to the
authentication module. We were destroying the users cookie if they tried to
re-connect. With the changes to have that information in local storage, that
broke our authentication process before it started. I suppose we'll have to
see if deleting the local storage objects as well now will work.
I just wanted to follow up in case someone found this thread and had a
similar issue with an update from an older version to the new version that
doesn't rely on cookies existence.
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
Re: Authentication Changes in 1.0.0
Posted by Mike Jumper <mj...@apache.org>.
On Wed, Feb 27, 2019 at 7:16 PM Lee <ld...@vt.edu> wrote:
> Auth Code: https://github.com/VTLee/guac-auth-ext
> ...
>
> Note how the second connection didn't even mention AuthenticationProvider
> --
> something bypassed that entire step (and there's no pathway that passes
> through getAuthorizedConfigurations that doesn't log a message). I have no
> way to alter this process within my extension anymore.
>
>
Nothing bypassed the step - your extension as written would have worked
this way for all releases of Guacamole, including 0.9.14. The
SimpleAuthenticationProvider class always caches the GuacamoleConfiguration
instances returned by getAuthorizedConfigurations().
The authenticateUser() function is invoked only at the beginning of the
user's session. Until the user logs out or their session expires (or they
use a different machine/browser that isn't logged in), this will only be
invoked once. After that point, the existing user will only be updated if
the extension implements updateAuthenticatedUser(). Data associated with
the session like connections, accessed via the UserContext returned by
getUserContext(), will similarly only be updated if updateUserContext() is
implemented.
> The intended functionality (that worked in 9.14) is for the user to be able
> to have several simultaneous connections to guacamole which route to
> different servers based on an initial cookie value which is used to lookup
> connection information (think: multiple tabs to different machines). The
> cookie is simply a one-time use primary key in a table that says the target
> machine info (host, port, protocol).
>
If you want the user's session to be updated when your cookie changes, you
will need to write an extension which implements updateUserContext() to
update the UserContext associated with their session with respect to that
cookie.
I suspect that if you retest your extension with 0.9.14, you'll find that
the behavior is unchanged, and the result of processing the cookie is still
cached.
- Mike
Re: Authentication Changes in 1.0.0
Posted by Lee <ld...@vt.edu>.
Auth Code: https://github.com/VTLee/guac-auth-ext
What I see: Only the first cookie matters. If I try to re-connect later, I
see no `logger.info()` messages that I used to see in
`getAuthorizedConfigurations`. It simply goes right into the previous
connection
Here's what I see in logs; First connection:
21:06:13.893 [http-nio-8080-exec-4] INFO myorg.ext.AuthenticationProvider -
Authenticated '9f263271-720c-4ec3-8df9-3342ed1cb059' to access the access
point: rdp://10.1.41.16:3389
21:06:13.913 [http-nio-8080-exec-4] INFO o.a.g.r.auth.AuthenticationService
- User "9f263271-720c-4ec3-8df9-3342ed1cb059" successfully authenticated
from [10.1.1.14, 10.1.6.31].
21:06:14.373 [http-nio-8080-exec-15] INFO o.a.g.environment.LocalEnvironment
- GUACAMOLE_HOME is "/root/.guacamole".
21:06:14.436 [http-nio-8080-exec-15] INFO o.a.g.tunnel.TunnelRequestService
- User "9f263271-720c-4ec3-8df9-3342ed1cb059" connected to connection
"2c28b2f6-156a-4f84-bbaa-7becffb92f00/ac454c62-387f-44aa-b129-352b6fce6d8d/012a5617-00aa-430c-9915-5e92e91b4d70".
21:06:20.856 [http-nio-8080-exec-12] INFO o.a.g.tunnel.TunnelRequestService
- User "9f263271-720c-4ec3-8df9-3342ed1cb059" disconnected from connection
"2c28b2f6-156a-4f84-bbaa-7becffb92f00/ac454c62-387f-44aa-b129-352b6fce6d8d/012a5617-00aa-430c-9915-5e92e91b4d70".
Duration: 6416 milliseconds
Connection with different cookie passed in (which the service would look up
and realize is a different server):
21:06:22.867 [http-nio-8080-exec-13] INFO o.a.g.environment.LocalEnvironment
- GUACAMOLE_HOME is "/root/.guacamole".
21:06:22.879 [http-nio-8080-exec-13] INFO o.a.g.tunnel.TunnelRequestService
- User "9f263271-720c-4ec3-8df9-3342ed1cb059" connected to connection
"2c28b2f6-156a-4f84-bbaa-7becffb92f00/ac454c62-387f-44aa-b129-352b6fce6d8d/012a5617-00aa-430c-9915-5e92e91b4d70".
21:06:24.541 [http-nio-8080-exec-12] INFO o.a.g.tunnel.TunnelRequestService
- User "9f263271-720c-4ec3-8df9-3342ed1cb059" disconnected from connection
"2c28b2f6-156a-4f84-bbaa-7becffb92f00/ac454c62-387f-44aa-b129-352b6fce6d8d/012a5617-00aa-430c-9915-5e92e91b4d70".
Duration: 1662 milliseconds
Note how the second connection didn't even mention AuthenticationProvider --
something bypassed that entire step (and there's no pathway that passes
through getAuthorizedConfigurations that doesn't log a message). I have no
way to alter this process within my extension anymore.
The intended functionality (that worked in 9.14) is for the user to be able
to have several simultaneous connections to guacamole which route to
different servers based on an initial cookie value which is used to lookup
connection information (think: multiple tabs to different machines). The
cookie is simply a one-time use primary key in a table that says the target
machine info (host, port, protocol).
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
Re: Authentication Changes in 1.0.0
Posted by Nick Couchman <vn...@apache.org>.
On Wed, Feb 27, 2019 at 18:06 Lee <ld...@vt.edu> wrote:
> Hello,
>
> I'm seeing a change in behavior I'm not sure how to work around. I'm
> using
> the docker image guacamole/guacamole:1.0.0 with a custom authentication
> provider extending SimpleAuthenticationProvider. With guacamole 0.9.14, I
> saw calls to getAuthorizedConfigurations in the authentication provider
> with
> every user request. This was great, as it allowed a single user to have
> multiple sessions open in separate tabs as the function could return
> different hosts/protocols/usernames/passwords.
Perhaps you could share your code? And what you're trying to accomplish?
You can have multiple connections open on the client in different tabs, and
you can link directly to these different connections, and each connection
can have its own host, protocol, username, and password.
-Nick