guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Couchman <>
Subject Re: Setting up HTTP header authentication
Date Thu, 21 Mar 2019 14:33:26 GMT
On Wed, Mar 20, 2019 at 6:24 PM Dmitry Katsubo <> wrote:

> Thanks for reply.
> On 2019-03-20 01:26, Nick Couchman wrote:
> This is where I get a little fuzzy - it's been quite a while since I
> actually used the file authentication module for much of anything.  I
> believe their may be some limitations to the stacking done with that module
> - that is, I don't know that the file authentication module actually
> recognizes the user accounts as authenticated from other modules.  I'm not
> saying for certain that it doesn't, just that there's some distant memory I
> have that maybe that module doesn't work that way, and that connections
> specified in the File provider will not necessarily be available to users
> authenticated through other modules.
> That's why I decided to ask here in this maillist before I jump into the
> source code. As I see from the source code of header auth module, it only
> creates an instance of AuthenticatedUser hence there should be some other
> module in the chain that can pick up the user name from that object and
> create GuacamoleConfiguration and UserContext for it. In its turn file
> auth does not allow null password, see Authorization:181
> <>
> hence this module will not deliver / populate connections for given user. I
> wonder how it is supposed to work?

I don't think that the not allowing of a null password is actually the
issue - I think the problem is that it just implements the
getAuthorizedConfigurations() method and not the authenticateUser() method,
which is what the other modules use to "stack" authentication.

> How Guacamole decides in which order to call providers? I order is
> undefined, then I don't see any reasonable way to make chaining possible.
> The only way out then is for HTTPHeaderAuthenticationProvider to extend
> FileAuthenticationProvider...

In general extensions are loaded and processed in alphabetical order, but
FileAuthenticationProvider is always loaded and processed last.  However,
the overall order only matters in certain corner cases for stacking, and,
in this case, the order does not matter so much as the fact that
FileAuthenticationProvider does not implement authenticateUser().  I could
be wrong about that, but I'm reasonably certain that's the issue.

> As for HTTPHeaderAuthenticationProvider implementation, I am a bit
> concerned. It uses such powerful tool as Guice / IoC just to perform static
> bindings? Then it's an overkill.

HTTPHeaderAuthenticationProvider only uses Guice to process configuration
information.  It is quite possible it is slightly overkill for this
implementation, and you're certainly welcome to propose changes and submit
pull requests if you have an idea of how it can be done more efficiently.

> You say that you don't get automatically connected to the VNC server - do
> you see the connection at all on the home screen?  Or is it a blank screen,
> with no connections?
> I don't see any connections on home screen. In other words, I see only
> blank white panes.

Yeah, this further indicates that the File provider does not stack with the
other modules.

> My suggestion would be to use the JDBC module to store connections.  It
> requires a little bit of extra work and a few extra resources to configure,
> but definitey works with the other modules and also gives you some
> flexibility in permission management among users.
> I would like not to go that way. Maybe it's not so complicated to setup,
> but I would like to keep everything simple.

That's understandable; however, this means you really have two options:
- Write a custom module, similar to the FileAuthenticationProvider, that
reads input from a file and stacks correctly with other modules.  This
should be pretty straight-forward, especially if you just want to write a
module that contains configurations and not actual authentication
information, and just map users or groups to those configurations.
- Propose changes to the FileAuthenticationProvider that allows it to
"stack" with the other modules, and (possibly, if you're up to it) submit a
pull request for those changes and have that functionality added to a
future version (1.1.0 scope is fixed, so it would be 1.2.0 or later).

>  The File provider handles both cases - either the single connection
> specified within the <authorize></authorize> context, or multiple
> connections specified within their own <connection></connection> contexts.
> Could you please put that phrase into documentation? As an option I can
> create a pull request.

We can be more explicit about it if you think it necessary, but I'm
reasonably certain the examples in the documentation cover both scenarios.



View raw message