You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by Dmitry Katsubo <dm...@mail.ru> on 2019/03/19 23:56:13 UTC
Setting up HTTP header authentication
Dear Guacamole community,
I have difficulties with setting up HTTP header authenticator. I have read the manual ([1]) but I still cannot make it working.
First of all I am not sure if I should set "auth-provider" property in /etc/guacamole/guacamole.properties, e.g. do I need to add:
auth-provider: org.apache.guacamole.auth.header.HTTPHeaderAuthenticationProvider
?
If I leave it unset, I get the following log:
20:38:21.077 [localhost-startStop-1] DEBUG o.a.g.extension.ExtensionModule - Loading extension: "guacamole-auth-header-1.0.0.jar"
20:38:21.708 [localhost-startStop-1] INFO o.a.g.extension.ExtensionModule - Extension "HTTP Header Authentication Extension" loaded.
20:38:21.914 [localhost-startStop-1] DEBUG o.a.g.extension.ExtensionModule - Binding AuthenticationProvider "org.apache.guacamole.auth.file.FileAuthenticationProvider".
...
20:38:35.919 [http-nio-127.0.0.1-8080-exec-5] INFO o.a.g.r.auth.AuthenticationService - User "admin" successfully authenticated from [10.14.1.22, 127.0.0.1].
20:38:35.922 [http-nio-127.0.0.1-8080-exec-5] DEBUG o.a.g.a.f.FileAuthenticationProvider - Reading user mapping file: "/etc/guacamole/user-mapping.xml"
20:38:35.949 [http-nio-127.0.0.1-8080-exec-5] DEBUG o.a.g.r.auth.AuthenticationService - Login was successful for user "admin".
and after I open Guacamole I see "admin" user name in right top corner (hence HTTP header authenticator worked OK), but I am not automatically connected to the server. I suppose I need to add an entry
to /etc/guacamole/user-mapping.xml, so I did:
<user-mapping>
<authorize username="admin">
<connection name="vnc">
<protocol>vnc</protocol>
<param name="hostname">vncserver</param>
<param name="port">5901</param>
<param name="password">secret</param>
<param name="clipboard-encoding">UTF-8</param>
</connection>
</authorize>
</user-mapping>
but that does not help (same result after restarting Tomcat). What I want to achieve is that authenticated user is automatically connected to VNC server.
Another note concerning the structure of user-mapping.xml. [2] reads the following:
Each user is specified with a corresponding <authorize> tag. This tag contains all authorized connections for that user, each denoted with a <connection> tag.
however one page before it provides an example where <authorize> tag not necessarily contains <connection>:
<authorize username="USERNAME" password="PASSWORD">
<protocol>vnc</protocol>
<param name="hostname">localhost</param>
<param name="port">5900</param>
<param name="password">VNCPASS</param>
</authorize>
So what is the rule: should <authorize> contain <connection>s tags or can it also describe one connection?
Addendum:
The connection prerequisites are certainly correct, as before I was using NoAuth provider without any complications:
11:40:29.188 [localhost-startStop-1] DEBUG o.a.g.extension.ExtensionModule - Loading extension: "guacamole-auth-noauth-1.0.0.jar"
11:40:29.319 [localhost-startStop-1] INFO o.a.g.extension.ExtensionModule - Extension "Disabled Authentication" loaded.
...
12:16:52.343 [http-nio-127.0.0.1-8080-exec-3] INFO o.a.g.r.auth.AuthenticationService - User "admin" successfully authenticated from [10.14.1.22, 127.0.0.1].
12:16:52.356 [http-nio-127.0.0.1-8080-exec-3] DEBUG o.a.g.a.n.NoAuthenticationProvider - Configuration file "/etc/guacamole/noauth-config.xml" has been modified.
12:16:52.356 [http-nio-127.0.0.1-8080-exec-3] DEBUG o.a.g.a.n.NoAuthenticationProvider - Reading configuration file: "/etc/guacamole/noauth-config.xml"
12:16:52.441 [http-nio-127.0.0.1-8080-exec-3] DEBUG o.a.g.r.auth.AuthenticationService - Login was successful for user "admin".
12:16:53.708 [http-nio-127.0.0.1-8080-exec-12] DEBUG o.a.g.net.InetGuacamoleSocket - Connecting to guacd at localhost:4822.
12:16:53.884 [http-nio-127.0.0.1-8080-exec-12] INFO o.a.g.tunnel.TunnelRequestService - User "admin" connected to connection "localhost".
[1] http://guacamole.apache.org/doc/gug/header-auth.html
[2] http://guacamole.apache.org/doc/gug/configuring-guacamole.html#basic-auth
Thanks for any help in advance.
--
With best regards,
Dmitry
Re: Setting up HTTP header authentication
Posted by Nick Couchman <vn...@apache.org>.
>
>
> Concerning contribution: where can I find the formatting rules for the
> project? The standards described here
> <https://directory.apache.org/fortress/coding-standards.html> do not
> match the current coding style... Also I cannot find any unit tests for the
> project. Are there any?
>
The site you referenced is for the Apache Directory project, not the
Guacamole project. Our main page is here:
http://guacamole.apache.org
And the contribution guidelines are here:
http://guacamole.apache.org/open-source/
With specific style guidelines noted here:
http://guacamole.apache.org/guac-style/
-Nick
Re: Setting up HTTP header authentication
Posted by Dmitry Katsubo <dm...@mail.ru>.
On 2019-03-22 21:42, Nick Couchman wrote:
>
>> Yes, we removed the NoAuth module without replacing it. The project determined that it was not worth continuing to keep it in the code, as the value was limited and the end-goal of the module
>> - transparently authenticating users into Guacamole - was possible by several other more secure means (SSO and parameter tokens, in particular). It's also true that the header module is very
>> simple - it accepts that a user has been authenticated up-stream and relies on other modules to provide configurations. This comes with a security caveat of its own - if you use the header
>> module it *must* be behind a reasonably secure front-end proxy that won't allow someone to spoof the header that is then accepted by the authentication module. There are warnings about this in
>> the manual.
> I agree. On the other hand, even if we make FileAuthenticationProvider work properly, JDBCAuthenticationProviderModule will still not work, as it requires username/password for authentication
> against the database. So if there is a need to stack JDBC/LDAP on the top of header authentication, one needs to agree how to enable that.
>
>
> This is not accurate - I've used the Header module with the JDBC module repeatedly, and it works fine, even without a password being provided. The JDBC module will recognize users authenticated by
> any other module - LDAP, Header, CAS, OpenID, RADIUS - regardless of whether the module sets a password on the Credential object. The File handler does not currently behave that way. The LDAP
> module, when used to store connections, also relies on both the username and password to be available because it binds to the LDAP tree with the provided username and password. The JDBC module uses
> a fixed username and password to access the database, and accepts authentication from other modules matching via username only.
I agree. After inspecting the code I saw that JDBC provider can process users authenticated by any other module.
Concerning contribution: where can I find the formatting rules for the project? The standards described here <https://directory.apache.org/fortress/coding-standards.html> do not match the current
coding style... Also I cannot find any unit tests for the project. Are there any?
--
With best regards,
Dmitry
Re: Setting up HTTP header authentication
Posted by Nick Couchman <vn...@apache.org>.
On Tue, May 24, 2022 at 6:31 AM Dmitry Katsubo <dm...@mail.ru.invalid>
wrote:
> I have analysed the code and I see that most of the classes (e.g. those
> needed to parse XML) are located in guacamole module, which probably
> cannot be used as dependency for an extension. So it looks that about 5
> classes are to be copied as is to "new extension" module. Does not smell
> good in terms of code reusability.
>
You should use gaucamole-ext as the dependency for the module, plus
whatever individual dependencies you need. If you have to add other
dependencies, that's fine - I think if you were to examine the pom.xml
files across the project you'd see that there are some dependencies that
are duplicated. Is it the maximumly-efficient way to go? Maybe not;
however, it allows the extensions to be pluggable/interchangeable, and for
the framework of Guacamole to be re-used for other things. It's a
trade-off, and sometimes absolutely efficiency is sacrificed for
compatibility, ease of reuse, etc.
> I am OK that the changes I suggest do not fit the common perception about
> how API should be organized. For me it is more logical to keep 10 lines of
> code patch that perfectly fits my needs rather than re-invent the extension
> that will be a copy-paste of existing code with no added value. At the end
> of the day that what OpenSource is about.
>
You're certainly welcome to modify the code you have to fit how you want to
do it - I would say _that_ is at least one of the things that Open Source
is about. As a project, our goals may be different from your individual
use-case, and that's okay - you have the source code, you can modify it as
you see fit. However, the changes that you've suggested are not ones that
we're willing to incorporate into the main code base for the project as
they stand today, for the reasons already mentioned.
-Nick
>
Re: Setting up HTTP header authentication
Posted by Dmitry Katsubo <dm...@mail.ru.INVALID>.
Thanks to everyone for his comments.
On 2022-05-19 17:20, Nick Couchman wrote:
> On Thu, May 19, 2022 at 10:52 AM Dmitry Katsubo <dm...@mail.ru.invalid> wrote:
>
>
> You mean that there are classes that extend SimpleAuthenticationProvider which are outside Guacamole git? Could be of course, however their adaptation will be trivial.
>
>
> Yes, but the point is that Guacamole is designed to provide not just a framework for itself, but one that people can build upon. With that in mind, API/ABI changes need to be very carefully
> considered, and also need to be made to be as backward-compatible as possible. In the past we've done things like deprecate methods or classes, but they remain available in the deprecated state for
> many releases before they are finally removed completely. The changes need to be made in such a way that they don't automatically break things for people who may be using/extending these classes,
> and that they have the option of continuing to use them in the way they are written while they change their code to the new way, but are warned that support for it may be removed/changed at some
> point in the future.
OK, I see.
>
>> For the built-in support for user-mapping.xml to be able to accept the authentication results of other installed extensions, it will need to be modified to use the less-simple API and implement
>> AuthenticationProvider and UserContext (rather than use SimpleAuthenticationProvider).
> I think that should be possible. AuthenticationProvider is already implemented, probably not the proper way (if so, what is missing?). As for UserContext I am not sure: none of the providers
> I've checked implement this interface. Maybe you mean that SimpleUserContext should implement that interface in a proper way (again what exactly is missing)?
>
>
> It is definitely possible, just needs to be done. I would also say it's worth considering leaving the existing user-mapping.xml authentication mechanism as-is and just implementing a different
> file-based one. It could be XML, or YAML, or JSON (or provide methods for reading any/all of those file types), and would be another extension in the "extensions/" folder.
I have analysed the code and I see that most of the classes (e.g. those needed to parse XML) are located in guacamole module, which probably cannot be used as dependency for an extension. So it looks
that about 5 classes are to be copied as is to "new extension" module. Does not smell good in terms of code reusability.
>
>> With user-mapping.xml really being intended for testing only, and with these changes aimed at allowing user-mapping.xml to be used in a more complex configuration aimed at production use, I
>> think these changes really would need to be coupled with a move to a user-mapping variant that /is/ intended for production (proper salted hashes for passwords instead of
>> intentionally-simplified-for-testing hashes, the ability to define a user/connection association that requires auth from some other extension and otherwise has no password, etc.).
> I think there are two things here mixed. The password which is used to authenticate the user against Guacamole is of course salted hashed and stored in guacamole_user SQL table. However in the
> setup I have the user is already authenticated by the front Web server, hence the password is null. There is nothing to salt or hash. On the other side the password stored in
> guacamole_connection_attribute table I believe is saved in plaintext, right? In this respect I don't see what else can be improved in user-mapping.xml which is basically another representation
> of the data in SQL database.
>
>
> What you're asking for is a way to simply store connections in a file and delegate the authentication elsewhere - the point is that the changes you've made to the built-in test authentication
> mechanism are not necessarily the best way to go about that, because you have to consider how other people will continue to use those mechanisms - will it break other things that rely on it, or will
> it encourage people to use those mechanisms in an insecure manner? This is another reason why I think implementing a separate file-based extension, rather than making tweaks to the built-in default
> one, is probably a better way to go.
>
I am OK that the changes I suggest do not fit the common perception about how API should be organized. For me it is more logical to keep 10 lines of code patch that perfectly fits my needs rather than
re-invent the extension that will be a copy-paste of existing code with no added value. At the end of the day that what OpenSource is about.
--
With best regards,
Dmitry
Re: Setting up HTTP header authentication
Posted by Nick Couchman <vn...@apache.org>.
On Thu, May 19, 2022 at 10:52 AM Dmitry Katsubo <dm...@mail.ru.invalid>
wrote:
> On 2022-05-19 01:44, Michael Jumper wrote:
>
> On Mon, May 16, 2022 at 12:23 PM Dmitry Katsubo <dm...@mail.ru.invalid>
> <dm...@mail.ru.invalid> wrote:
>
>> Dear Guacamole users,
>> Dear Nick,
>>
>> Sorry I decided to resurrect the 4-years old challenge. I have rebased my
>> changes on the latest codebase. Not so many changes are required to allow
>> the user authenticated via auth-header extension to be provided
>> authentication information / connection settings from user-mapping.xml.
>> Without the changes the settings are not picked up from user-mapping.xml.
>>
>
> Is there a specific reason that you cannot use the database? It's intended
> for what you describe, intended for production use, and will work with
> header auth.
>
> I think that database is overkill for systems that have a couple of users
> (e.g. remote admins). Files are easier to maintain and backup, as all
> Guacamole configuration is basically located in one place. Also imagine the
> situation when database is down and could be fixed with help of Guacamole
> unless it is running on the top of that very database.
>
> Please check my commit b0aa658
>> <https://github.com/dmak/guacamole-client/commit/b0aa658043689b8ff37d18db49a75ac443b4cc12>.
>> If that is OK, then I would provide few unit tests for it. Otherwise let me
>> know what is missing, preferably in terms so that I can implement a test.
>>
>
> Looking at your commit, I see that one of the primary changes here is
> changing the prototype and visibility of the getAuthorizedConfigurations()
> function. This will break API and ABI compatibility, and I do not think we
> should do this.
>
> You mean that there are classes that extend SimpleAuthenticationProvider
> which are outside Guacamole git? Could be of course, however their
> adaptation will be trivial.
>
Yes, but the point is that Guacamole is designed to provide not just a
framework for itself, but one that people can build upon. With that in
mind, API/ABI changes need to be very carefully considered, and also need
to be made to be as backward-compatible as possible. In the past we've done
things like deprecate methods or classes, but they remain available in the
deprecated state for many releases before they are finally removed
completely. The changes need to be made in such a way that they don't
automatically break things for people who may be using/extending these
classes, and that they have the option of continuing to use them in the way
they are written while they change their code to the new way, but are
warned that support for it may be removed/changed at some point in the
future.
> For the built-in support for user-mapping.xml to be able to accept the
> authentication results of other installed extensions, it will need to be
> modified to use the less-simple API and implement AuthenticationProvider
> and UserContext (rather than use SimpleAuthenticationProvider).
>
> I think that should be possible. AuthenticationProvider is already
> implemented, probably not the proper way (if so, what is missing?). As for
> UserContext I am not sure: none of the providers I've checked implement
> this interface. Maybe you mean that SimpleUserContext should implement
> that interface in a proper way (again what exactly is missing)?
>
It is definitely possible, just needs to be done. I would also say it's
worth considering leaving the existing user-mapping.xml authentication
mechanism as-is and just implementing a different file-based one. It could
be XML, or YAML, or JSON (or provide methods for reading any/all of those
file types), and would be another extension in the "extensions/" folder.
> With user-mapping.xml really being intended for testing only, and with
> these changes aimed at allowing user-mapping.xml to be used in a more
> complex configuration aimed at production use, I think these changes really
> would need to be coupled with a move to a user-mapping variant that *is* intended
> for production (proper salted hashes for passwords instead of
> intentionally-simplified-for-testing hashes, the ability to define a
> user/connection association that requires auth from some other extension
> and otherwise has no password, etc.).
>
> I think there are two things here mixed. The password which is used to
> authenticate the user against Guacamole is of course salted hashed and
> stored in guacamole_user SQL table. However in the setup I have the user
> is already authenticated by the front Web server, hence the password is
> null. There is nothing to salt or hash. On the other side the password
> stored in guacamole_connection_attribute table I believe is saved in
> plaintext, right? In this respect I don't see what else can be improved in
> user-mapping.xml which is basically another representation of the data in
> SQL database.
>
What you're asking for is a way to simply store connections in a file and
delegate the authentication elsewhere - the point is that the changes
you've made to the built-in test authentication mechanism are not
necessarily the best way to go about that, because you have to consider how
other people will continue to use those mechanisms - will it break other
things that rely on it, or will it encourage people to use those mechanisms
in an insecure manner? This is another reason why I think implementing a
separate file-based extension, rather than making tweaks to the built-in
default one, is probably a better way to go.
-Nick
>
Re: Setting up HTTP header authentication
Posted by Dmitry Katsubo <dm...@mail.ru.INVALID>.
On 2022-05-19 01:44, Michael Jumper wrote:
> On Mon, May 16, 2022 at 12:23 PM Dmitry Katsubo <dm...@mail.ru.invalid> wrote:
>
> Dear Guacamole users,
> Dear Nick,
>
> Sorry I decided to resurrect the 4-years old challenge. I have rebased my changes on the latest codebase. Not so many changes are required to allow the user authenticated via auth-header
> extension to be provided authentication information / connection settings from user-mapping.xml. Without the changes the settings are not picked up from user-mapping.xml.
>
>
> Is there a specific reason that you cannot use the database? It's intended for what you describe, intended for production use, and will work with header auth.
I think that database is overkill for systems that have a couple of users (e.g. remote admins). Files are easier to maintain and backup, as all Guacamole configuration is basically located in one
place. Also imagine the situation when database is down and could be fixed with help of Guacamole unless it is running on the top of that very database.
>
> Please check my commit b0aa658 <https://github.com/dmak/guacamole-client/commit/b0aa658043689b8ff37d18db49a75ac443b4cc12>. If that is OK, then I would provide few unit tests for it. Otherwise
> let me know what is missing, preferably in terms so that I can implement a test.
>
>
> Looking at your commit, I see that one of the primary changes here is changing the prototype and visibility of the getAuthorizedConfigurations() function. This will break API and ABI compatibility,
> and I do not think we should do this.
You mean that there are classes that extend SimpleAuthenticationProvider which are outside Guacamole git? Could be of course, however their adaptation will be trivial.
> For the built-in support for user-mapping.xml to be able to accept the authentication results of other installed extensions, it will need to be modified to use the less-simple API and implement
> AuthenticationProvider and UserContext (rather than use SimpleAuthenticationProvider).
I think that should be possible. AuthenticationProvider is already implemented, probably not the proper way (if so, what is missing?). As for UserContext I am not sure: none of the providers I've
checked implement this interface. Maybe you mean that SimpleUserContext should implement that interface in a proper way (again what exactly is missing)?
> With user-mapping.xml really being intended for testing only, and with these changes aimed at allowing user-mapping.xml to be used in a more complex configuration aimed at production use, I think
> these changes really would need to be coupled with a move to a user-mapping variant that /is/ intended for production (proper salted hashes for passwords instead of
> intentionally-simplified-for-testing hashes, the ability to define a user/connection association that requires auth from some other extension and otherwise has no password, etc.).
I think there are two things here mixed. The password which is used to authenticate the user against Guacamole is of course salted hashed and stored in guacamole_user SQL table. However in the setup I
have the user is already authenticated by the front Web server, hence the password is null. There is nothing to salt or hash. On the other side the password stored in guacamole_connection_attribute
table I believe is saved in plaintext, right? In this respect I don't see what else can be improved in user-mapping.xml which is basically another representation of the data in SQL database.
From another side if the changes I suggest break some other flow that you have in mind, like proper data flow in conjunction with some other extension – please let me know how can I reproduce the
issue, so that I can improve the code changes I suggested.
Many thanks!
--
With best regards,
Dmitry
Re: Setting up HTTP header authentication
Posted by Michael Jumper <mj...@apache.org>.
On Mon, May 16, 2022 at 12:23 PM Dmitry Katsubo <dm...@mail.ru.invalid>
wrote:
> Dear Guacamole users,
> Dear Nick,
>
> Sorry I decided to resurrect the 4-years old challenge. I have rebased my
> changes on the latest codebase. Not so many changes are required to allow
> the user authenticated via auth-header extension to be provided
> authentication information / connection settings from user-mapping.xml.
> Without the changes the settings are not picked up from user-mapping.xml.
>
Is there a specific reason that you cannot use the database? It's intended
for what you describe, intended for production use, and will work with
header auth.
> Please check my commit b0aa658
> <https://github.com/dmak/guacamole-client/commit/b0aa658043689b8ff37d18db49a75ac443b4cc12>.
> If that is OK, then I would provide few unit tests for it. Otherwise let me
> know what is missing, preferably in terms so that I can implement a test.
>
Looking at your commit, I see that one of the primary changes here is
changing the prototype and visibility of the getAuthorizedConfigurations()
function. This will break API and ABI compatibility, and I do not think we
should do this.
For the built-in support for user-mapping.xml to be able to accept the
authentication results of other installed extensions, it will need to be
modified to use the less-simple API and implement AuthenticationProvider
and UserContext (rather than use SimpleAuthenticationProvider).
With user-mapping.xml really being intended for testing only, and with
these changes aimed at allowing user-mapping.xml to be used in a more
complex configuration aimed at production use, I think these changes really
would need to be coupled with a move to a user-mapping variant that
*is* intended
for production (proper salted hashes for passwords instead of
intentionally-simplified-for-testing hashes, the ability to define a
user/connection association that requires auth from some other extension
and otherwise has no password, etc.).
- Mike
Re: Setting up HTTP header authentication
Posted by Dmitry Katsubo <dm...@mail.ru.INVALID>.
Dear Guacamole users,
Dear Nick,
Sorry I decided to resurrect the 4-years old challenge. I have rebased my changes on the latest codebase. Not so many changes are required to allow the user authenticated via auth-header extension to
be provided authentication information / connection settings from user-mapping.xml. Without the changes the settings are not picked up from user-mapping.xml.
Please check my commit b0aa658 <https://github.com/dmak/guacamole-client/commit/b0aa658043689b8ff37d18db49a75ac443b4cc12>. If that is OK, then I would provide few unit tests for it. Otherwise let me
know what is missing, preferably in terms so that I can implement a test.
On 2019-03-22 21:42, Nick Couchman wrote:
>
>> Yes, we removed the NoAuth module without replacing it. The project determined that it was not worth continuing to keep it in the code, as the value was limited and the end-goal of the module
>> - transparently authenticating users into Guacamole - was possible by several other more secure means (SSO and parameter tokens, in particular). It's also true that the header module is very
>> simple - it accepts that a user has been authenticated up-stream and relies on other modules to provide configurations. This comes with a security caveat of its own - if you use the header
>> module it *must* be behind a reasonably secure front-end proxy that won't allow someone to spoof the header that is then accepted by the authentication module. There are warnings about this in
>> the manual.
> I agree. On the other hand, even if we make FileAuthenticationProvider work properly, JDBCAuthenticationProviderModule will still not work, as it requires username/password for authentication
> against the database. So if there is a need to stack JDBC/LDAP on the top of header authentication, one needs to agree how to enable that.
>
>
> This is not accurate - I've used the Header module with the JDBC module repeatedly, and it works fine, even without a password being provided. The JDBC module will recognize users authenticated by
> any other module - LDAP, Header, CAS, OpenID, RADIUS - regardless of whether the module sets a password on the Credential object. The File handler does not currently behave that way. The LDAP
> module, when used to store connections, also relies on both the username and password to be available because it binds to the LDAP tree with the provided username and password. The JDBC module uses
> a fixed username and password to access the database, and accepts authentication from other modules matching via username only.
>
On 2019-03-26 00:30, Nick Couchman wrote:
> The site you referenced is for the Apache Directory project, not the Guacamole project. Our main page is here:
>
> http://guacamole.apache.org
>
> And the contribution guidelines are here:
>
> http://guacamole.apache.org/open-source/
>
> With specific style guidelines noted here:
>
> http://guacamole.apache.org/guac-style/
--
With best regards,
Dmitry
Re: Setting up HTTP header authentication
Posted by Nick Couchman <vn...@apache.org>.
>
> Yes, we removed the NoAuth module without replacing it. The project
> determined that it was not worth continuing to keep it in the code, as the
> value was limited and the end-goal of the module - transparently
> authenticating users into Guacamole - was possible by several other more
> secure means (SSO and parameter tokens, in particular). It's also true
> that the header module is very simple - it accepts that a user has been
> authenticated up-stream and relies on other modules to provide
> configurations. This comes with a security caveat of its own - if you use
> the header module it *must* be behind a reasonably secure front-end proxy
> that won't allow someone to spoof the header that is then accepted by the
> authentication module. There are warnings about this in the manual.
>
> I agree. On the other hand, even if we make FileAuthenticationProvider
> work properly, JDBCAuthenticationProviderModule will still not work, as
> it requires username/password for authentication against the database. So
> if there is a need to stack JDBC/LDAP on the top of header authentication,
> one needs to agree how to enable that.
>
This is not accurate - I've used the Header module with the JDBC module
repeatedly, and it works fine, even without a password being provided. The
JDBC module will recognize users authenticated by any other module - LDAP,
Header, CAS, OpenID, RADIUS - regardless of whether the module sets a
password on the Credential object. The File handler does not currently
behave that way. The LDAP module, when used to store connections, also
relies on both the username and password to be available because it binds
to the LDAP tree with the provided username and password. The JDBC module
uses a fixed username and password to access the database, and accepts
authentication from other modules matching via username only.
-Nick
>
Re: Setting up HTTP header authentication
Posted by Dmitry Katsubo <dm...@mail.ru>.
On 2019-03-22 01:54, Nick Couchman wrote:
> On Thu, Mar 21, 2019 at 8:38 PM Dmitry Katsubo <dma_k@mail.ru <ma...@mail.ru>> wrote:
>
> Nick, if you check SimpleAuthenticationProvider.authenticateUser():142 <https://github.com/apache/guacamole-client/blob/7e7b6fde4cd63ac8ec21e2ee900ae865d15a4c36/guacamole-ext/src/main/java/org/apache/guacamole/net/auth/simple/SimpleAuthenticationProvider.java#L142> you will see that if there are configurations available, user is created on-the-fly.
> Further look into the source code revealed that things are a bit more complicated. All modules perform user comparison based on the information from Credentials instance, see for example UserService.retrieveAuthenticatedUser():361 <https://github.com/apache/guacamole-client/blob/658ce7884695cbe0c04b29f0b6fa365312dbe2fd/extensions/guacamole-auth-jdbc/modules/guacamole-auth-jdbc-base/src/main/java/org/apache/guacamole/auth/jdbc/user/UserService.java#L361> and the only place where this object is created at is TokenRESTService.getCredentials() <https://github.com/apache/guacamole-client/blob/c890919d5bbb9ccc8243f04caae07c78a032ef07/guacamole/src/main/java/org/apache/guacamole/rest/auth/TokenRESTService.java#L84>. That in its turn means that Guacamole cannot create Credentials instance other than from Authorization: Basic HTTP header, which means that front webserver/proxy authorization (which is not necessarily HTTP basic authentication) is not possible.
>
>
> I think I understand what you're saying. To be sure, the header module does work - it will authenticate a user passed through from a Nginx or httpd header authentication. However, it will not pass through a password to the File authentication provider (since there is not usually a password present), so if the File authentication provider module requires that password in order to retrieve the configuration, it will fail. Maybe this is what you're saying.
>
>
>
> * FileAuthenticationProvider.java.patch – this one overrides getUserContext() to enable configuration for authenticatedUser.getIdentifier().
> * AuthenticatedUser_Authorization.patch – this one injects username from header to Credentials and allows null passwords.
>
> If you wish to contribute these you'll need to follow the contribution procedure for the project, which generally means creating a JIRA issue and then a pull request.
I am OK to contribute one of above patches but you / Guacamole team need to decide which way to go:
* Either we go the way that FileAuthenticationProvider "understands" authenticatedUser.getIdentifier() and allows null passwords for that username.
* Or we make HTTPHeaderAuthenticationProvider to set username also to Credentials, but then FileAuthenticationProvider still needs to allow null passwords.
So what do we choose?
> Yes, we removed the NoAuth module without replacing it. The project determined that it was not worth continuing to keep it in the code, as the value was limited and the end-goal of the module - transparently authenticating users into Guacamole - was possible by several other more secure means (SSO and parameter tokens, in particular). It's also true that the header module is very simple - it accepts that a user has been authenticated up-stream and relies on other modules to provide configurations. This comes with a security caveat of its own - if you use the header module it *must* be behind a reasonably secure front-end proxy that won't allow someone to spoof the header that is then accepted by the authentication module. There are warnings about this in the manual.
I agree. On the other hand, even if we make FileAuthenticationProvider work properly, JDBCAuthenticationProviderModule will still not work, as it requires username/password for authentication against the database. So if there is a need to stack JDBC/LDAP on the top of header authentication, one needs to agree how to enable that.
--
With best regards,
Dmitry
Re: Setting up HTTP header authentication
Posted by Nick Couchman <vn...@apache.org>.
On Thu, Mar 21, 2019 at 8:38 PM Dmitry Katsubo <dm...@mail.ru> wrote:
> On 2019-03-21 00:12, brian mullan wrote:
>
> On 2019-03-21 15:33, Nick Couchman wrote:
>
> 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.
>
> Nick, if you check SimpleAuthenticationProvider.authenticateUser():142
> <https://github.com/apache/guacamole-client/blob/7e7b6fde4cd63ac8ec21e2ee900ae865d15a4c36/guacamole-ext/src/main/java/org/apache/guacamole/net/auth/simple/SimpleAuthenticationProvider.java#L142>
> you will see that if there are configurations available, user is created
> on-the-fly.
> Further look into the source code revealed that things are a bit more
> complicated. All modules perform user comparison based on the information
> from Credentials instance, see for example
> UserService.retrieveAuthenticatedUser():361
> <https://github.com/apache/guacamole-client/blob/658ce7884695cbe0c04b29f0b6fa365312dbe2fd/extensions/guacamole-auth-jdbc/modules/guacamole-auth-jdbc-base/src/main/java/org/apache/guacamole/auth/jdbc/user/UserService.java#L361>
> and the only place where this object is created at is
> TokenRESTService.getCredentials()
> <https://github.com/apache/guacamole-client/blob/c890919d5bbb9ccc8243f04caae07c78a032ef07/guacamole/src/main/java/org/apache/guacamole/rest/auth/TokenRESTService.java#L84>.
> That in its turn means that Guacamole cannot create Credentials instance
> other than from Authorization: Basic HTTP header, which means that front
> webserver/proxy authorization (which is not necessarily HTTP basic
> authentication) is not possible.
>
I think I understand what you're saying. To be sure, the header module
does work - it will authenticate a user passed through from a Nginx or
httpd header authentication. However, it will not pass through a password
to the File authentication provider (since there is not usually a password
present), so if the File authentication provider module requires that
password in order to retrieve the configuration, it will fail. Maybe this
is what you're saying.
>
> I have identified the following workarounds, namely, if one of below
> patches is applied then everything starts working:
>
> - FileAuthenticationProvider.java.patch – this one overrides
> getUserContext() to enable configuration for
> authenticatedUser.getIdentifier().
> - AuthenticatedUser_Authorization.patch – this one injects username
> from header to Credentials and allows null passwords.
>
>
>
If you wish to contribute these you'll need to follow the contribution
procedure for the project, which generally means creating a JIRA issue and
then a pull request.
> 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.
>
> With my respect to GUACAMOLE-493
> <https://issues.apache.org/jira/browse/GUACAMOLE-493> and GUACAMOLE-256
> <https://issues.apache.org/jira/browse/GUACAMOLE-256> after removing
> guacamole-auth-noauth Guacamole provided no means to replace it. It
> actually did what you say, and only was missing a header check.
>
>
Yes, we removed the NoAuth module without replacing it. The project
determined that it was not worth continuing to keep it in the code, as the
value was limited and the end-goal of the module - transparently
authenticating users into Guacamole - was possible by several other more
secure means (SSO and parameter tokens, in particular). It's also true
that the header module is very simple - it accepts that a user has been
authenticated up-stream and relies on other modules to provide
configurations. This comes with a security caveat of its own - if you use
the header module it *must* be behind a reasonably secure front-end proxy
that won't allow someone to spoof the header that is then accepted by the
authentication module. There are warnings about this in the manual.
> - 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).
>
> As I shown above, "stacking" of FileAuthenticationProvider is possible,
> but requires opening other doors, which I am not sure is correct.
>
>
Agreed - it is definitely possible, it just won't work today as implemented.
-Nick
Re: Setting up HTTP header authentication
Posted by Dmitry Katsubo <dm...@mail.ru>.
On 2019-03-21 00:12, brian mullan wrote:
> Maybe I missed it but what linux distro are you using ?
Brian, I think it does not matter so much. I have compiled guacd from sources for Debian Buster and I have downloaded guacamole.war v1.0.0 from Apache website.
On 2019-03-21 15:33, Nick Couchman wrote:
> 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.
Nick, if you check SimpleAuthenticationProvider.authenticateUser():142
<https://github.com/apache/guacamole-client/blob/7e7b6fde4cd63ac8ec21e2ee900ae865d15a4c36/guacamole-ext/src/main/java/org/apache/guacamole/net/auth/simple/SimpleAuthenticationProvider.java#L142> you
will see that if there are configurations available, user is created on-the-fly.
Further look into the source code revealed that things are a bit more complicated. All modules perform user comparison based on the information from Credentials instance, see for example
UserService.retrieveAuthenticatedUser():361
<https://github.com/apache/guacamole-client/blob/658ce7884695cbe0c04b29f0b6fa365312dbe2fd/extensions/guacamole-auth-jdbc/modules/guacamole-auth-jdbc-base/src/main/java/org/apache/guacamole/auth/jdbc/user/UserService.java#L361>
and the only place where this object is created at is TokenRESTService.getCredentials()
<https://github.com/apache/guacamole-client/blob/c890919d5bbb9ccc8243f04caae07c78a032ef07/guacamole/src/main/java/org/apache/guacamole/rest/auth/TokenRESTService.java#L84>. That in its turn means that
Guacamole cannot create Credentials instance other than from Authorization: Basic HTTP header, which means that front webserver/proxy authorization (which is not necessarily HTTP basic authentication)
is not possible.
I have identified the following workarounds, namely, if one of below patches is applied then everything starts working:
* FileAuthenticationProvider.java.patch – this one overrides getUserContext() to enable configuration for authenticatedUser.getIdentifier().
* AuthenticatedUser_Authorization.patch – this one injects username from header to Credentials and allows null passwords.
>
>
> 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.
Thanks. I confirm that is exactly as you say.
>
>
> 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.
With my respect to GUACAMOLE-493 <https://issues.apache.org/jira/browse/GUACAMOLE-493> and GUACAMOLE-256 <https://issues.apache.org/jira/browse/GUACAMOLE-256> after removing guacamole-auth-noauth
Guacamole provided no means to replace it. It actually did what you say, and only was missing a header check.
> - 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).
As I shown above, "stacking" of FileAuthenticationProvider is possible, but requires opening other doors, which I am not sure is correct.
>
>
>> 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.
>
>
> http://guacamole.apache.org/doc/gug/configuring-guacamole.html#basic-auth
>
> 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.
>
Thanks for comments & explanations!
--
With best regards,
Dmitry
Re: Setting up HTTP header authentication
Posted by Nick Couchman <vn...@apache.org>.
On Wed, Mar 20, 2019 at 6:24 PM Dmitry Katsubo <dm...@mail.ru> 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
> <https://github.com/apache/guacamole-client/blob/d1e928bea79ca81c827e9b6adedabc98eefdf701/guacamole/src/main/java/org/apache/guacamole/auth/file/Authorization.java#L181>
> 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.
>
http://guacamole.apache.org/doc/gug/configuring-guacamole.html#basic-auth
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.
-Nick
>
Re: Setting up HTTP header authentication
Posted by brian mullan <bm...@gmail.com>.
Maybe I missed it but what linux distro are you using ?
On Wed, Mar 20, 2019, 6:24 PM Dmitry Katsubo <dm...@mail.ru> 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
> <https://github.com/apache/guacamole-client/blob/d1e928bea79ca81c827e9b6adedabc98eefdf701/guacamole/src/main/java/org/apache/guacamole/auth/file/Authorization.java#L181>
> hence this module will not deliver / populate connections for given user. I
> wonder how it is supposed to work?
> 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...
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> --
> With best regards,
> Dmitry
>
>
Re: Setting up HTTP header authentication
Posted by Dmitry Katsubo <dm...@mail.ru>.
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 <https://github.com/apache/guacamole-client/blob/d1e928bea79ca81c827e9b6adedabc98eefdf701/guacamole/src/main/java/org/apache/guacamole/auth/file/Authorization.java#L181> hence
this module will not deliver / populate connections for given user. I wonder how it is supposed to work?
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...
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.
> 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.
> 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.
> 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.
--
With best regards,
Dmitry
Re: Setting up HTTP header authentication
Posted by Nick Couchman <vn...@apache.org>.
On Tue, Mar 19, 2019 at 7:56 PM Dmitry Katsubo <dm...@mail.ru> wrote:
> Dear Guacamole community,
>
> I have difficulties with setting up HTTP header authenticator. I have read
> the manual ([1]) but I still cannot make it working.
>
> First of all I am not sure if I should set "auth-provider" property in
> /etc/guacamole/guacamole.properties, e.g. do I need to add:
>
> auth-provider:
> org.apache.guacamole.auth.header.HTTPHeaderAuthenticationProvider
>
No, you do not need this - this option has been completely removed from the
code and has no effect.
>
> ?
>
> If I leave it unset, I get the following log:
>
> 20:38:21.077 [localhost-startStop-1] DEBUG o.a.g.extension.ExtensionModule
> - Loading extension: "guacamole-auth-header-1.0.0.jar"
> 20:38:21.708 [localhost-startStop-1] INFO o.a.g.extension.ExtensionModule
> - Extension "HTTP Header Authentication Extension" loaded.
> 20:38:21.914 [localhost-startStop-1] DEBUG o.a.g.extension.ExtensionModule
> - Binding AuthenticationProvider
> "org.apache.guacamole.auth.file.FileAuthenticationProvider".
> ...
> 20:38:35.919 [http-nio-127.0.0.1-8080-exec-5] INFO
> o.a.g.r.auth.AuthenticationService - User "admin" successfully
> authenticated from [10.14.1.22, 127.0.0.1].
> 20:38:35.922 [http-nio-127.0.0.1-8080-exec-5] DEBUG
> o.a.g.a.f.FileAuthenticationProvider - Reading user mapping file:
> "/etc/guacamole/user-mapping.xml"
> 20:38:35.949 [http-nio-127.0.0.1-8080-exec-5] DEBUG
> o.a.g.r.auth.AuthenticationService - Login was successful for user "admin".
>
This is good - it indicates that the HEADER module is installed correctly,
loading, and functioning.
>
> and after I open Guacamole I see "admin" user name in right top corner
> (hence HTTP header authenticator worked OK), but I am not automatically
> connected to the server. I suppose I need to add an entry
> to /etc/guacamole/user-mapping.xml, so I did:
>
> <user-mapping>
> <authorize username="admin">
> <connection name="vnc">
> <protocol>vnc</protocol>
> <param name="hostname">vncserver</param>
> <param name="port">5901</param>
> <param name="password">secret</param>
> <param name="clipboard-encoding">UTF-8</param>
> </connection>
> </authorize>
> </user-mapping>
>
> but that does not help (same result after restarting Tomcat). What I want
> to achieve is that authenticated user is automatically connected to VNC
> server.
>
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.
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?
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.
>
> Another note concerning the structure of user-mapping.xml. [2] reads the
> following:
>
> Each user is specified with a corresponding <authorize> tag. This tag
> contains all authorized connections for that user, each denoted with a
> <connection> tag.
>
> however one page before it provides an example where <authorize> tag not
> necessarily contains <connection>:
>
> <authorize username="USERNAME" password="PASSWORD">
> <protocol>vnc</protocol>
> <param name="hostname">localhost</param>
> <param name="port">5900</param>
> <param name="password">VNCPASS</param>
> </authorize>
>
> So what is the rule: should <authorize> contain <connection>s tags or can
> it also describe one connection?
>
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.
-Nick