Re: How to allow "WebSocket | HTTP tunnel request" with IPv6?

[Henri Alves de Godoy]

Hi Nick and Willy,

sorry i missed this message

enable ipv6 socket in your tomcat

 

It should work now.

Att,
Henri


Em sex., 22 de jul. de 2022 às 22:44, Nick Couchman 
escreveu:

> On Thu, Apr 21, 2022 at 4:36 AM Willy Manga  wrote:
> >
> > Hi Alves,
> >
> > On 19/04/2022 15:32, Henri Alves de Godoy wrote:
> > > Hi Willy,
> > >
> > > Assuming that your server where the tomcat/guacd daemon is is
> dual-stack
> > > and your internal environment is IPv6-only
> >
> > What if I want to avoid any IPv4 config ..
> >
>
> I would think you just need to enable IPv6 in Tomcat. There's nothing
> about Guacamole that is specific to one version or another - the
> default to IPv4 is a Tomcat configuration.
>
> -Nick
>
> -
> To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
> For additional commands, e-mail: user-h...@guacamole.apache.org
>
>

--

Re: How to allow "WebSocket | HTTP tunnel request" with IPv6?

[Nick Couchman]

On Thu, Apr 21, 2022 at 4:36 AM Willy Manga  wrote:
>
> Hi Alves,
>
> On 19/04/2022 15:32, Henri Alves de Godoy wrote:
> > Hi Willy,
> >
> > Assuming that your server where the tomcat/guacd daemon is is dual-stack
> > and your internal environment is IPv6-only
>
> What if I want to avoid any IPv4 config ..
>

I would think you just need to enable IPv6 in Tomcat. There's nothing
about Guacamole that is specific to one version or another - the
default to IPv4 is a Tomcat configuration.

-Nick

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

Re: Setting up HTTP header authentication

[Nick Couchman]

On Tue, May 24, 2022 at 6:31 AM Dmitry Katsubo 
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

[Dmitry Katsubo]

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  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

[Nick Couchman]

On Thu, May 19, 2022 at 10:52 AM Dmitry Katsubo 
wrote:

> On 2022-05-19 01:44, Michael Jumper wrote:
>
> On Mon, May 16, 2022 at 12:23 PM Dmitry Katsubo 
>  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
>> .
>> 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 

Re: New protocol 'http/https'

[Nick Couchman]

On Thu, May 19, 2022 at 3:48 AM Lionel PRAT  wrote:

> Hi,
>
> I'm looking for a solution to use guacamole to limit access to certain web
> administration interfaces (firewall, vmware, ...).
>
> I had thought of using a chrome in VNC but I find this solution too
> dangerous.
> The best solution would surely be to develop a connector for the
> 'http/https' protocol (perhaps starting from the existing code in the
> connector
> https://github.com/apache/guacamole-server/tree/master/src/protocols/
>  kubernetes).
> Has anyone had this problem before and if so, how did you resolve it?
>
>
This has come up several times, and, to date, we have not really seriously
entertained the idea and have kind of pushed back against it. The
conversation in the past has been that Guacamole has been targeted toward
remote desktop protocols, and HTTP/HTTPS are not remote desktop protocols.
Furthermore, there are plenty of solutions out there to proxy/reverse-proxy
HTTP and HTTPS pages, and those could be used in place of Guacamole. We may
be shifting a bit on this, but, today, it isn't possible to use HTTP/HTTPS
through guacd.

Several alternatives have been offered that continue to use Guacamole - for
example, you can set up a remote server running RDP or VNC and create a
remote connection to that server, and you can even have the remote
connection open only a web browser, and you could even do it in Kiosk mode
with either Firefox or Chrome to prevent users from using it for other web
pages.

Beyond that, adding HTTP/HTTPS support is possible, but I would not say
it's all that straight-forward. We've had some conversations about how it
could be done, and it seems like we would need to use some sort of back-end
rendering engine that guacd could interface with (there are a couple of
good ones out there) and then write the logic to translate between the
rendering engine and the Guacamole protocol. Definitely possible, just not
easy. And I'm not sure the Kubernetes protocol is a great place to start -
it's text-only, similar to Telnet and SSH, whereas the HTTP/HTTPS protocol
is going to need to be graphics-based, more along the lines of VNC or RDP.

-Nick

>

Re: Setting up HTTP header authentication

[Dmitry Katsubo]

On 2022-05-19 01:44, Michael Jumper wrote:
> On Mon, May 16, 2022 at 12:23 PM Dmitry Katsubo  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 
> .
>  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

New protocol 'http/https'

[Lionel PRAT]

Hi,

I'm looking for a solution to use guacamole to limit access to certain web
administration interfaces (firewall, vmware, ...).

I had thought of using a chrome in VNC but I find this solution too
dangerous.
The best solution would surely be to develop a connector for the
'http/https' protocol (perhaps starting from the existing code in the
connector
https://github.com/apache/guacamole-server/tree/master/src/protocols/
 kubernetes).
Has anyone had this problem before and if so, how did you resolve it?

Thank you

Lionel

Re: Setting up HTTP header authentication

[Michael Jumper]

On Mon, May 16, 2022 at 12:23 PM Dmitry Katsubo 
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
> .
> 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: question:guacamole connection slow over https but not on http

[Rao, Amit]

Thanks Mike, you for reply , but I was able to increase performance by using 
application load balancer over https .


Thanks and Regards
Amit Rao

From: Michael Jumper 
Sent: Tuesday, May 17, 2022 10:49 AM
To: user@guacamole.apache.org
Subject: Re: question:guacamole connection slow over https but not on http

On Mon, May 16, 2022, 21:53 Rao, Amit 
mailto:amit@verint.com.invalid>> wrote:

Hi  ,



I have configured Guacamole in AWS ECS using fargate which has following 
architecture .

My issue is when I rdp to any server on 443 https then connection takes extra 5 
second to load but when I use http connection is almost immediate .



My nginx conf is below . can you please help what am I missing ?

Perhaps the host system is rapidly running out of entropy? It's common for 
virtualized systems to have a hard time generating enough entropy for the 
secure random number generation required for cryptography.

- Mike



This electronic message may contain proprietary and confidential information of 
Verint Systems Inc., its affiliates and/or subsidiaries. The information is 
intended to be for the use of the individual(s) or entity(ies) named above. If 
you are not the intended recipient (or authorized to receive this e-mail for 
the intended recipient), you may not use, copy, disclose or distribute to 
anyone this message or any information contained in this message. If you have 
received this electronic message in error, please notify us by replying to this 
e-mail.

Re: question:guacamole connection slow over https but not on http

[Michael Jumper]

On Mon, May 16, 2022, 21:53 Rao, Amit  wrote:

> Hi  ,
>
>
>
> I have configured Guacamole in AWS ECS using fargate which has following
> architecture .
>
> My issue is when I rdp to any server on 443 https then connection takes
> extra 5 second to load but when I use http connection is almost immediate .
>
>
>
> My nginx conf is below . can you please help what am I missing ?
>

Perhaps the host system is rapidly running out of entropy? It's common for
virtualized systems to have a hard time generating enough entropy for the
secure random number generation required for cryptography.

- Mike

question:guacamole connection slow over https but not on http

[Rao, Amit]

Hi  ,



I have configured Guacamole in AWS ECS using fargate which has following 
architecture .

My issue is when I rdp to any server on 443 https then connection takes extra 5 
second to load but when I use http connection is almost immediate .



My nginx conf is below . can you please help what am I missing ?

server {
listen   80;
listen  [::]:80;
server_name  dockerconnect.dev.verint.training  ;


#access_log  /var/log/nginx/host.access.log  main;
location /request {

proxy_pass http://request:3001/;

proxy_buffering off;

proxy_http_version 1.1;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;

proxy_set_header X-Real-IP $remote_addr;

proxy_cookie_path /guacamole/ /guacamole/;

access_log off;

}

location /status {

proxy_pass http://status:3002/;

proxy_buffering off;

proxy_http_version 1.1;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection $http_connection;

proxy_set_header X-Real-IP $remote_addr;

proxy_cookie_path /guacamole/ /guacamole/;

access_log off;

}
location /timer {
proxy_pass http://timer:3005/;
proxy_buffering off;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_cookie_path /guacamole/ /guacamole/;
access_log off;
}
location /expired {
proxy_pass http://timer:3005/expired;
proxy_buffering off;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_cookie_path /guacamole/ /guacamole/;
access_log off;
}
location /links {
proxy_pass http://links:3008/links;
proxy_buffering off;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_cookie_path /guacamole/ /guacamole/;
access_log off;
}

location / {
proxy_pass http://guacamole:8080/guacamole/;
proxy_buffering off;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_cookie_path /guacamole/ /;
access_log off;
}

#error_page  404  /404.html;

# redirect server error pages to the static page /50x.html
#
error_page   500 502 503 504  /50x.html;
location = /50x.html {
root   /usr/share/nginx/html;
}

# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
#proxy_pass   http://127.0.0.1;
#}

# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
#root   html;
#fastcgi_pass   127.0.0.1:9000;
#fastcgi_index  index.php;
#fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
#includefastcgi_params;
#}

# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
#deny  all;
#}
}




[cid:image001.png@01D869D6.562012D0]





Thanks and Regards

Amit Rao




This electronic message may contain proprietary and confidential information of 
Verint Systems Inc., its affiliates and/or subsidiaries. The information is 
intended to be for the use of the individual(s) or entity(ies) named above. If 
you are not the intended recipient (or authorized to receive this e-mail for 
the intended recipient), you may not use, copy, disclose or distribute to 
anyone this message or any information contained in this message. If you have 
received this electronic message in error, please notify us by replying to this 
e-mail.

Re: Setting up HTTP header authentication

[Dmitry Katsubo]

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: How to allow "WebSocket | HTTP tunnel request" with IPv6?

[Willy Manga]

Hi Alves,

On 19/04/2022 15:32, Henri Alves de Godoy wrote:

Hi Willy,

Assuming that your server where the tomcat/guacd daemon is is dual-stack
and your internal environment is IPv6-only


What if I want to avoid any IPv4 config ..

Here's what I want


+--+
| Network of hosts |
| using IPv6-only  |
+--+
|
|
| (IPv6)
|
+-+
|Guacamole/Tomcat |
+-+
|
|
| (IPv6)
|
+-+
|  Nginx  |
+-+
|
|
(IPv4)  | (IPv6)
|
+-+
|   Internet  |
+-+




In the host configuration, put the IPv6 of the remote machine you want to
access.


I don't have any issue accessing v6 hosts provided by guacamole.


You can also change in guacd to bind the v6 address of localhost ::1


Here is my issue. By default, when you build from scratch guacamole 1.4 
on debian 11, it will listen to ::1 . That setup will not work unless I 
missed something.


I had to tell guacd to bind to 127.0.0.1 :(

Otherwise I got this


Apr 21 10:29:12 guac2 tomcat9[1811]: 10:29:12.870 [http-nio-8080-exec-6] 
INFO  o.a.g.r.auth.AuthenticationService - User "gogo" successfully 
authenticated from 2001:db8:43:cafe::1.


Apr 21 10:29:14 guac2 tomcat9[1811]: 10:29:14.423 [http-nio-8080-exec-9] 
ERROR o.a.g.w.GuacamoleWebSocketTunnelEndpoint - Creation of WebSocket 
tunnel to guacd failed: java.net.ConnectException: Connection refused 
(Connection refused)


Apr 21 10:29:15 guac2 tomcat9[1811]: 10:29:15.369 [http-nio-8080-exec-1] 
ERROR o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request failed: 
java.net.ConnectException: Connection refused (Connection refused)



--
Willy Manga
@ongolaboy
https://ongola.blogspot.com/


OpenPGP_signature
Description: OpenPGP digital signature

Re: How to allow "WebSocket | HTTP tunnel request" with IPv6?

[Henri Alves de Godoy]

Hi Willy,

Assuming that your server where the tomcat/guacd daemon is is dual-stack
and your internal environment is IPv6-only

In the host configuration, put the IPv6 of the remote machine you want to
access.

You can also change in guacd to bind the v6 address of localhost ::1

It works without any problems.

Att,
Henri

Em ter., 19 de abr. de 2022 às 08:25, Willy Manga 
escreveu:

> Hi,
>
> I have installed guacamole and got the following errors [1] after a
> successful authentication.
>
> I'm aware of [2] where the solution was to set bind_host to 127.0.0.1
> [3]. My question is how to allow that tunnel request in an IPv6-only
> environment?
>
> The 'Connection refused' seems like an issue with a service not allowed
> in IPv6 somewhere within tomcat
>
> In my setup, I use debian 11, guacamole 1.4 ... I'm planning to use v4
> address only on the nginx proxy.
>
> 1. https://paste.debian.net/1238366/
>
> 2. https://lists.apache.org/thread/ttv4sc6jlbso1pfwpd1yo43ssk0rnwoz
>
> 3. https://lists.apache.org/thread/dm3coj38x3fhco0gxnyw0k22lwcp5wwy
>
> --
> Willy Manga
> @ongolaboy
> https://ongola.blogspot.com/
>


--

How to allow "WebSocket | HTTP tunnel request" with IPv6?

[Willy Manga]

Hi,

I have installed guacamole and got the following errors [1] after a 
successful authentication.


I'm aware of [2] where the solution was to set bind_host to 127.0.0.1 
[3]. My question is how to allow that tunnel request in an IPv6-only 
environment?


The 'Connection refused' seems like an issue with a service not allowed 
in IPv6 somewhere within tomcat


In my setup, I use debian 11, guacamole 1.4 ... I'm planning to use v4 
address only on the nginx proxy.


1. https://paste.debian.net/1238366/

2. https://lists.apache.org/thread/ttv4sc6jlbso1pfwpd1yo43ssk0rnwoz

3. https://lists.apache.org/thread/dm3coj38x3fhco0gxnyw0k22lwcp5wwy

--
Willy Manga
@ongolaboy
https://ongola.blogspot.com/


OpenPGP_signature
Description: OpenPGP digital signature

Re: HTTP tunnel request failed

[Nick Couchman]

On Wed, Mar 30, 2022 at 5:40 AM Max  wrote:

> Hi:
>
> After a couple of days going crazy with this problem, I figured out how to
> solve it so just leaving this here for future google surfers:
>
> Suddenly my guacamole server stopped working, the logs just showed this
> error:
>
> 11:03:14.552 [ajp-nio-8009-exec-3] DEBUG o.a.g.net.InetGuacamoleSocket -
> Connecting to guacd at localhost:4822. 11:03:14.553
>
> [ajp-nio-8009-exec-3] ERROR o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel 
> request failed: java.net.ConnectException:  Connection refused (Connection 
> refused)
>
> After a lot of search, I used 127.0.0.1 instead of localhost in the 
> guacamole.properties as it worked for other people but no for me.
>
> guacd-hostname: 127.0.0.1
> guacd-port: 4822
>
>
> Until I noticed that the guacd service was listening in ::1 but not in
> 127.0.0.1
>
> Proxy daemon (guacd) version 1.4.0 started mar 30 11:00:33 Server1 
> guacd[1300]: SUCCESS mar 30 11:00:33 Kalandraka guacd[1303]: Listening on 
> host ::1, port 4822
>
> So, as I am not using Ipv6, just disabled it adding this entry:
>
> net.ipv6.conf.all.disable_ipv6 = 1
>
> To the /etc/sysctl.conf file and restart the system.
>
>
You can also force guacd to listen on the IPv4 port, without disabling IPv6
altogether. You do this by setting "bind_host" to 127.0.0.1 in
/etc/guacd.conf. See:

https://guacamole.apache.org/doc/gug/configuring-guacamole.html#configuring-guacd

-Nick

HTTP tunnel request failed

[Max]

Hi:
After a couple of days going crazy with this problem, I figured out how to 
solve it so just leaving this here for future google surfers:
Suddenly my guacamole server stopped working, the logs just showed this error:
11:03:14.552 [ajp-nio-8009-exec-3] DEBUG o.a.g.net.InetGuacamoleSocket - 
Connecting to guacd at localhost:4822. 11:03:14.553 
[ajp-nio-8009-exec-3] ERROR o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel 
request failed: java.net.ConnectException:  Connection refused (Connection 
refused)After a lot of search, I used 127.0.0.1 instead of localhost in the 
guacamole.properties as it worked for other people but no for me.
guacd-hostname: 127.0.0.1
guacd-port: 4822 
Until I noticed that the guacd service was listening in ::1 but not in 
127.0.0.1 

Proxy daemon (guacd) version 1.4.0 started mar 30 11:00:33 Server1 guacd[1300]: 
SUCCESS mar 30 11:00:33 Kalandraka guacd[1303]: Listening on host ::1, port 
4822So, as I am not using Ipv6, just disabled it adding this entry:
net.ipv6.conf.all.disable_ipv6 = 1
To the /etc/sysctl.conf file and restart the system.
Now It works fine.
I hope this helps someone.
Best regards

RE: Proxying Guacamole with Apache2 HTTP Server and SAML - New issue with 1.4

[Martin Twerski]

On Thu, Feb 10, 2022 at 11:14 AM Martin Twerski 
mailto:mar...@tigunia.com>> wrote:
Upgraded from 1.3 to 1.4 where I had SAML working. I have updated the plugin to 
the new sso one. I get an error when trying to use SAML auth  -  
[http-nio-8080-exec-2] WARN  o.a.g.a.s.a.AssertionConsumerServiceResource - 
Authentication attempted with an invalid SAML response: SAML response did not 
pass validation: The response was received at 
http://example.fqdn.com/guacamole/api/ext/saml/callback instead of 
https://example.fqdn.com/api/ext/saml/callback

If I set saml-strict to false, no issues with login. If I revert to 1.3 plugin, 
no issues.

My reverse proxy in front of Guacamole is Apache. I have followed this: 
https://guacamole.apache.org/doc/0.9.7/gug/proxying-guacamole.html (The section 
about  “Apache and mod_proxy” as well as “Setting up the Remote IP Valve”).

My proxy is not on the same box as Guacamole.

Any ideas on how to resolve this?

Instead of changing the path of the application within the proxy, try renaming 
"guacamole.war" to "ROOT.war" so that Tomcat serves the application from / 
directly.

I also recommend looking at the docs for the current release:

https://guacamole.apache.org/doc/gug/reverse-proxy.html

The link you reference above is a snapshot of ancient 0.9.7 docs (6+ years ago).

- Mike

Mike,
Thanks for the link to the current docs. I was using an old bookmark and didn’t 
realize it was a versioned copy.

I don’t think the path is the issue – it appears to be an http vs https issue. 
I have switched it to the root (rename war file to ROOT.war) and now get this 
error:
[http-nio-8080-exec-4] WARN  o.a.g.a.s.a.AssertionConsumerServiceResource - 
Authentication attempted with an invalid SAML response: SAML response did not 
pass validation: The response was received at 
http://example.fqdn.com/api/ext/saml/callback instead of 
https://example.fqdn.com/api/ext/saml/callback
How do I get Guacamole to “receive the response” at https?

Try adding the "X-Forwarded-Proto" header via your proxy config. The HTTP side 
of the proxied connection probably can't otherwise tell that the user-facing 
side is actually HTTPS.

- Mike

That seemed to solve it. Thanks for all your help!

Re: Proxying Guacamole with Apache2 HTTP Server and SAML - New issue with 1.4

[Mike Jumper]

On Thu, Feb 10, 2022 at 11:14 AM Martin Twerski  wrote:

> Upgraded from 1.3 to 1.4 where I had SAML working. I have updated the
> plugin to the new sso one. I get an error when trying to use SAML auth  -
> [http-nio-8080-exec-2] WARN  o.a.g.a.s.a.AssertionConsumerServiceResource -
> Authentication attempted with an invalid SAML response: SAML response did
> not pass validation: The response was received at
> http://example.fqdn.com/guacamole/api/ext/saml/callback instead of
> https://example.fqdn.com/api/ext/saml/callback
>
>
>
> If I set saml-strict to false, no issues with login. If I revert to 1.3
> plugin, no issues.
>
>
>
> My reverse proxy in front of Guacamole is Apache. I have followed this:
> https://guacamole.apache.org/doc/0.9.7/gug/proxying-guacamole.html (The
> section about  “Apache and mod_proxy” as well as “Setting up the Remote IP
> Valve”).
>
>
>
> My proxy is not on the same box as Guacamole.
>
>
>
> Any ideas on how to resolve this?
>
>
>
> Instead of changing the path of the application within the proxy, try
> renaming "guacamole.war" to "ROOT.war" so that Tomcat serves the
> application from / directly.
>
>
>
> I also recommend looking at the docs for the current release:
>
>
>
> https://guacamole.apache.org/doc/gug/reverse-proxy.html
>
>
>
> The link you reference above is a snapshot of ancient 0.9.7 docs (6+ years
> ago).
>
>
>
> - Mike
>
>
>
> Mike,
>
> Thanks for the link to the current docs. I was using an old bookmark and
> didn’t realize it was a versioned copy.
>
>
>
> I don’t think the path is the issue – it appears to be an http vs https
> issue. I have switched it to the root (rename war file to ROOT.war) and now
> get this error:
>
> [http-nio-8080-exec-4] WARN  o.a.g.a.s.a.AssertionConsumerServiceResource
> - Authentication attempted with an invalid SAML response: SAML response did
> not pass validation: The response was received at
> http://example.fqdn.com/api/ext/saml/callback instead of
> https://example.fqdn.com/api/ext/saml/callback
>
> How do I get Guacamole to “receive the response” at https?
>

Try adding the "X-Forwarded-Proto" header via your proxy config. The HTTP
side of the proxied connection probably can't otherwise tell that the
user-facing side is actually HTTPS.

- Mike

Re: Proxying Guacamole with Apache2 HTTP Server and SAML - New issue with 1.4

[Mike Jumper]

On Thu, Feb 10, 2022, 10:37 Martin Twerski  wrote:

> Upgraded from 1.3 to 1.4 where I had SAML working. I have updated the
> plugin to the new sso one. I get an error when trying to use SAML auth  -
> [http-nio-8080-exec-2] WARN  o.a.g.a.s.a.AssertionConsumerServiceResource -
> Authentication attempted with an invalid SAML response: SAML response did
> not pass validation: The response was received at
> http://example.fqdn.com/guacamole/api/ext/saml/callback instead of
> https://example.fqdn.com/api/ext/saml/callback
>
>
>
> If I set saml-strict to false, no issues with login. If I revert to 1.3
> plugin, no issues.
>
>
>
> My reverse proxy in front of Guacamole is Apache. I have followed this:
> https://guacamole.apache.org/doc/0.9.7/gug/proxying-guacamole.html (The
> section about  “Apache and mod_proxy” as well as “Setting up the Remote IP
> Valve”).
>
>
>
> My proxy is not on the same box as Guacamole.
>
>
>
> Any ideas on how to resolve this?
>

Instead of changing the path of the application within the proxy, try
renaming "guacamole.war" to "ROOT.war" so that Tomcat serves the
application from / directly.

I also recommend looking at the docs for the current release:

https://guacamole.apache.org/doc/gug/reverse-proxy.html

The link you reference above is a snapshot of ancient 0.9.7 docs (6+ years
ago).

- Mike

Proxying Guacamole with Apache2 HTTP Server and SAML - New issue with 1.4

[Martin Twerski]

Upgraded from 1.3 to 1.4 where I had SAML working. I have updated the plugin to 
the new sso one. I get an error when trying to use SAML auth  -  
[http-nio-8080-exec-2] WARN  o.a.g.a.s.a.AssertionConsumerServiceResource - 
Authentication attempted with an invalid SAML response: SAML response did not 
pass validation: The response was received at 
http://example.fqdn.com/guacamole/api/ext/saml/callback instead of 
https://example.fqdn.com/api/ext/saml/callback

If I set saml-strict to false, no issues with login. If I revert to 1.3 plugin, 
no issues.

My reverse proxy in front of Guacamole is Apache. I have followed this: 
https://guacamole.apache.org/doc/0.9.7/gug/proxying-guacamole.html (The section 
about  "Apache and mod_proxy" as well as "Setting up the Remote IP Valve").

My proxy is not on the same box as Guacamole.

Any ideas on how to resolve this?

Re: HTTP mothods

[Cyrus]

El lun, 13 sept 2021 a las 11:20, Nick Couchman () escribió:
>
> On Mon, Sep 13, 2021 at 10:57 AM Ciro Iriarte  wrote:
>>
>> Hello!,
>>
>> Is there any documentation about which HTTP methods are needed by Guacamole?.
>>
>> Besides the usual suspects (GET/HEAD/POST), I found references for
>> DELETE in the Glyptodon bug tracker & PATCH in the documentation about
>> proxying Guacamole (not sure it's still required).
>>
>> Is there an official summary?. I'm trying to comply with security
>> guidelines without breaking functionality. :)
>>
>
> I don't know of an official summary, but I believe you you've got them 
> covered in the list above.
>
> -NIck

Hello!,

Got bit by this trying to change group access to some hosts. PUT is also needed.

Sharing that for posterity.

Regards,

-- 
Ciro Iriarte
http://iriarte.it
--

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

Re: HTTP

[Nick Couchman]

On Thu, Dec 16, 2021 at 3:42 AM Paula Carboné 
wrote:

> Hi!
> Will it be possible for Guacamole to grant access to HTTP(S) pages? I know
> Guacamole itself does not provide such access but I wonder if his could be
> done and how.
> Any ideas?
> Thanks!
>
>
This really depends on what you mean by "grant access." There are a couple
of options that I can think of, and that have been discussed previously, in
the absence of Guacamole supporting HTTP(S) directly:
* A custom extension could be written to display links on the Guacamole
home page that would be available to users. You could also use Guacamole's
user/group management to control what users and groups see these links.
However, this is a very passive access control - Guacamole would not be
actually controlling access to the servers or pages, because traffic would
not actually be going through Guacamole, it would just be controlling what
is displayed for the users. As long as the web pages that are linked have
proper access control and authentication, this isn't necessarily a problem,
but it is worth noting.
* You could also configure a connection to a RDP Server (or Remote App) or
VNC Server that launches a web browser that displays the web page that you
want to provide access to. The access control provided by both Guacamole
and the Remote Server would more actively protect the destination URLs,
particularly if they are behind a firewall.

-Nick

HTTP

[Paula Carboné]

Hi!
Will it be possible for Guacamole to grant access to HTTP(S) pages? I know
Guacamole itself does not provide such access but I wonder if his could be
done and how.
Any ideas?
Thanks!

BR

Re: HTTP mothods

[Nick Couchman]

On Mon, Sep 13, 2021 at 10:57 AM Ciro Iriarte  wrote:

> Hello!,
>
> Is there any documentation about which HTTP methods are needed by
> Guacamole?.
>
> Besides the usual suspects (GET/HEAD/POST), I found references for
> DELETE in the Glyptodon bug tracker & PATCH in the documentation about
> proxying Guacamole (not sure it's still required).
>
> Is there an official summary?. I'm trying to comply with security
> guidelines without breaking functionality. :)
>
>
I don't know of an official summary, but I believe you you've got them
covered in the list above.

-NIck

HTTP mothods

[Ciro Iriarte]

Hello!,

Is there any documentation about which HTTP methods are needed by Guacamole?.

Besides the usual suspects (GET/HEAD/POST), I found references for
DELETE in the Glyptodon bug tracker & PATCH in the documentation about
proxying Guacamole (not sure it's still required).

Is there an official summary?. I'm trying to comply with security
guidelines without breaking functionality. :)

Regards,
CI.-

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

Re: HTTP Connection

[Nick Couchman]

On Wed, Aug 11, 2021 at 9:17 AM Wade Gibson 
wrote:

> I'm relatively new to the guac world, but so far have set up fourteen
> servers on Ubuntu with Let's Encrypt and MFA. We're seeing abundant uses
> for remote access with vendors and other outside parties who need to manage
> internal systems remotely.
>
> One thing that we've discovered we would really like is the ability to
> have a connection type that's an emulated HTTP/HTTPS browser session where
> we can control what internal web service/address a user can connect to. We
> love the simplicity and security that guac gives us by having a single URL
> to give vendors to access their equipment without having to set up gobs of
> port forwards and firewall rules, but sometimes all we need is to have a
> management web interface accessible and not a full RDP or VNC connection.
>
>
Wade,
While I don't have any direct links to threads right now, this has been
asked and discussed in the past. There was even a JIRA issue opened for it:
https://issues.apache.org/jira/browse/GUACAMOLE-57

The gist of it is that we do not intend to make Guacamole into a generic
VPN client or reverse proxy. We are focused on providing a robust,
clientless remote desktop gateway, and support popular remote desktop
protocols. Reverse proxying HTTP/HTTPS is something we are not interested
in doing.

There should be ways to use either Apache httpd or Nginx to accomplish what
you're trying to do - Nginx in particular, I know, can take a URL argument
and proxy it through, and I would imagine Apache httpd can do similar
things. You can also secure both of those platforms in their reverse proxy
capacity with various authentication mechanisms.


> We're experimenting with running a Linux client VM that automatically pops
> up a Firefox kiosk when connecting with VNC, but it isn't really scalable
> for us. Has anyone run into this type of use case that may have a better
> workaround?
>
>
If you're crunched for time, and just need a solution, then I think this is
a great idea - it uses existing protocol support in Guacamole, and can
present it in a, more or less, seamless fashion to the end users. The only
other thing I suggest would be that, if VNC doesn't work for you, you can
try xrdp on Linux and use that, instead - particularly if Audio support is
required, or multi-user access, session management, etc., - things that VNC
isn't particularly good at, then xrdp may allow you to accomplish some of
these items. xrdp has great support for allowing you to customize what's
being launched (window manager, specific application, etc.), so that might
be better for you. You can also use Guacamole's built-in support for Load
Balancing connection groups to spread the load across multiple servers.

-Nick

>

HTTP Connection

[Wade Gibson]

I'm relatively new to the guac world, but so far have set up fourteen
servers on Ubuntu with Let's Encrypt and MFA. We're seeing abundant uses
for remote access with vendors and other outside parties who need to manage
internal systems remotely.

One thing that we've discovered we would really like is the ability to have
a connection type that's an emulated HTTP/HTTPS browser session where we
can control what internal web service/address a user can connect to. We
love the simplicity and security that guac gives us by having a single URL
to give vendors to access their equipment without having to set up gobs of
port forwards and firewall rules, but sometimes all we need is to have a
management web interface accessible and not a full RDP or VNC connection.

We're experimenting with running a Linux client VM that automatically pops
up a Firefox kiosk when connecting with VNC, but it isn't really scalable
for us. Has anyone run into this type of use case that may have a better
workaround?

/> Wade Gibson
/> ESU 11

Re: Support - HTTP Fallback is not working correctly in some cases

[Nick Couchman]

On Thu, Jul 8, 2021 at 4:21 AM Alex B.  wrote:

> Can be. My problem is that I need to use Guacamole on a network where some
> part of the websocket protocol is prohibited. I know that Guacamole can
> work only with HTTP, but it looks like some part of WS needs to be used
> (and is blocked on the restricted network). Using 404 is working well on an
> unrestricted network , but when I'm on the restricted network, then I don´t
> get 404, but 500.
>
>>
>>
The fact that you're continuing to receive 500 error messages means that
something else is going on. It could be an error from the Tomcat server
that is being passed through the proxy, it could be the proxy, or, given
the fact that you've said this is a "restricted network", it could be that
some other firewall is interfering with the communication and generating
the HTTP 500 errors. You'll need to look carefully at the logs and
determine why these errors are occuring - it would be better to solve that
issue, first, and then deal with making sure that WS support is properly
disabled.

-Nick

Re: Support - HTTP Fallback is not working correctly in some cases

[Mike Jumper]

On Thu, Jul 8, 2021, 01:21 Alex B.  wrote:

> Can be. My problem is that I need to use Guacamole on a network where some
> part of the websocket protocol is prohibited. I know that Guacamole can
> work only with HTTP, but it looks like some part of WS needs to be used
> (and is blocked on the restricted network). Using 404 is working well on an
> unrestricted network , but when I'm on the restricted network, then I don´t
> get 404, but 500.
>

Architecturally, no, WebSocket is definitely not required. WebSocket is
tried first, and HTTP is used if this fails. It's that simple.

For failover to HTTP to not occur, WebSocket would have to initially work -
enough for Guacamole to move forward with using it. If WebSocket fails
outright, HTTP is used.

- Mike

Re: Support - HTTP Fallback is not working correctly in some cases

[Alex B.]

Can be. My problem is that I need to use Guacamole on a network where some
part of the websocket protocol is prohibited. I know that Guacamole can
work only with HTTP, but it looks like some part of WS needs to be used
(and is blocked on the restricted network). Using 404 is working well on an
unrestricted network , but when I'm on the restricted network, then I don´t
get 404, but 500.


čt 8. 7. 2021 v 10:11 odesílatel Christoph Weber 
napsal:

>
> > thanks for the quick reply, but I want to achieve the opposite -> I need
> to force Guacamole to not use websocket.
>
> I'm not sure, but as websocket upgrade requires a response code of 101 to
> work, and a test with a server not supporting websockets just returns 200,
> maybe returning 200 instead of 404 will work.
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
> For additional commands, e-mail: user-h...@guacamole.apache.org
>

AW: Support - HTTP Fallback is not working correctly in some cases

[Christoph Weber]

> thanks for the quick reply, but I want to achieve the opposite -> I need to 
> force Guacamole to not use websocket.

I'm not sure, but as websocket upgrade requires a response code of 101 to work, 
and a test with a server not supporting websockets just returns 200, maybe 
returning 200 instead of 404 will work.


-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

Re: Support - HTTP Fallback is not working correctly in some cases

[Alex B.]

Hi Christoph,

thanks for the quick reply, but I want to achieve the opposite -> I need to
force Guacamole to not use websocket.

Alex.

čt 8. 7. 2021 v 8:53 odesílatel Christoph Weber 
napsal:

> > Please see full nginx.conf. I do it like that:
> >location /websocket-tunnel {
> >return 404;
> >error_page 500 501 502 503 504 505 506 507 508 509 510 511
> 598 599 = /404.html;
> >proxy_buffering off;
> >}
>
> Hi alex,
>
> I think you must also set the connection upgrade headers for this location
> when using websockets - like this:
> proxy_set_header Upgrade $http_upgrade;
> proxy_set_header Connection $connection_upgrade;
>
> regards
>  christoph
>

AW: Support - HTTP Fallback is not working correctly in some cases

[Christoph Weber]

> Please see full nginx.conf. I do it like that:
>        location /websocket-tunnel {
>            return 404;
>            error_page 500 501 502 503 504 505 506 507 508 509 510 511 598 599 
>= /404.html;
>            proxy_buffering off;
>        }

Hi alex,

I think you must also set the connection upgrade headers for this location when 
using websockets - like this:
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;

regards
 christoph

Re: Support - HTTP Fallback is not working correctly in some cases

[Alex B.]

Hi Nick,

thanks for reply. I will try to answer your questions:


>
> Hi,
>>
>> I´m trying to run Guacamole on some restricted network. On the normal
>> network it is working well, but on restricted network (there is general
>> problem with using Websockets). I´m not able to see any picture (connection
>> is established, because Windows 10 on the other site will be locked after
>> connection).
>>
>> I´m using reverse proxy to disable any WS communication (I have a rule
>> to send location /websocket-tunnel to 404).
>>
>
> Can you provide more detail on how you're doing this? Depending on your
> reverse proxy, simply configuring a location that sends /websocket-tunnel
> to a 404 not found error may not actually be achieving what you think it is
> achieving - you may be rediecting http://server/guacamole/webscoket-tunnel
> rather than wss://server/guacamole/websocket-tunnel.
>

Please see full nginx.conf. I do it like that:
location /websocket-tunnel {
return 404;
error_page 500 501 502 503 504 505 506 507 508 509 510 511 598
599 = /404.html;
proxy_buffering off;
}



>
>
>>
>> I tried to compare "ok" state and this state. Only what I find is the
>> response code from Websocket connection to
>> 'ws://:/websocket-tunnel'. In both cases this call failed,
>> but in "ok" state it will fail without any message, but in second case, it
>> will fail with message: Error during WebSocket handshake: Unexpected
>> response code: 500.
>>
>
> I'm not sure what you mean when you say you compared it?
>

I tried to compare two different networks and result of same action. When I
try to connect to RDP, I will get following results:

Restricted network:
[image: image.png]

Not restricted network:
[image: image.png]


>
>
>>
>> I tried to redirect all 500 codes to 404, but without success.
>>
>
> This is a Bad Idea, and will both 1) not achieve what you want, and 2)
> cause misleading issues in the future.
>

Agree with you. In this stage is not production state and I´m trying lot of
options to get it work. This setting is not working neither.


>
>
>>
>> Can you please help me with this? I don´t know if it is an application
>> error (bug), or if my setup is wrong or if Guacamole cannot be used on
>> "WebSocket restricted" networks at all...
>>
>>
> Guacamole can certainly be configured to work without WSS, we just need
> more detail on how you've tried to go about this in order to help you.
>
>
All my effort is based on this article:
https://jira.glyptodon.com/browse/GUAC-1474. In this article is
recommended to redirect Websocket to 404. Unfortunately, I´m not able to
find any other article, where is described how to run Guacamole without WSS.



> -Nick
>
>>
Thanks in advance

Alex.


nginx.conf
Description: Binary data

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

Re: Support - HTTP Fallback is not working correctly in some cases

[Nick Couchman]

On Wed, Jul 7, 2021 at 1:53 PM Alex B.  wrote:

> Hi,
>
> I´m trying to run Guacamole on some restricted network. On the normal
> network it is working well, but on restricted network (there is general
> problem with using Websockets). I´m not able to see any picture (connection
> is established, because Windows 10 on the other site will be locked after
> connection).
>
> I´m using reverse proxy to disable any WS communication (I have a rule
> to send location /websocket-tunnel to 404).
>

Can you provide more detail on how you're doing this? Depending on your
reverse proxy, simply configuring a location that sends /websocket-tunnel
to a 404 not found error may not actually be achieving what you think it is
achieving - you may be rediecting http://server/guacamole/webscoket-tunnel
rather than wss://server/guacamole/websocket-tunnel.


>
> I tried to compare "ok" state and this state. Only what I find is the
> response code from Websocket connection to
> 'ws://:/websocket-tunnel'. In both cases this call failed,
> but in "ok" state it will fail without any message, but in second case, it
> will fail with message: Error during WebSocket handshake: Unexpected
> response code: 500.
>

I'm not sure what you mean when you say you compared it?


>
> I tried to redirect all 500 codes to 404, but without success.
>

This is a Bad Idea, and will both 1) not achieve what you want, and 2)
cause misleading issues in the future.


>
> Can you please help me with this? I don´t know if it is an application
> error (bug), or if my setup is wrong or if Guacamole cannot be used on
> "WebSocket restricted" networks at all...
>
>
Guacamole can certainly be configured to work without WSS, we just need
more detail on how you've tried to go about this in order to help you.

-Nick

>

Support - HTTP Fallback is not working correctly in some cases

[Alex B.]

Hi,

I´m trying to run Guacamole on some restricted network. On the normal
network it is working well, but on restricted network (there is general
problem with using Websockets). I´m not able to see any picture (connection
is established, because Windows 10 on the other site will be locked after
connection).

I´m using reverse proxy to disable any WS communication (I have a rule
to send location /websocket-tunnel to 404).

I tried to compare "ok" state and this state. Only what I find is the
response code from Websocket connection to
'ws://:/websocket-tunnel'. In both cases this call failed,
but in "ok" state it will fail without any message, but in second case, it
will fail with message: Error during WebSocket handshake: Unexpected
response code: 500.

I tried to redirect all 500 codes to 404, but without success.

Can you please help me with this? I don´t know if it is an application
error (bug), or if my setup is wrong or if Guacamole cannot be used on
"WebSocket restricted" networks at all...

Thanks

Alex.

Re: Is there a way to add an HTTP(s) connection as a Connection

[Nick Couchman]

On Mon, Jun 28, 2021 at 2:30 PM Charles Mccrea 
wrote:

> Hello Forum,
>
> I've been using Guacamole Server as way to allow remote users to access
> via SSH and RDP without issue.  But I have a use case whereby I would like
> to grant access through Guacamole to a webpage. Is this possible?
>
>
No - Guacamole is a remote desktop client, and is not intended to be a
reverse proxy or full VPN solution. We've been asked many times about
adding HTTP(S) rendering to Guacamole, and there are many, many challenges
to this that we believe are out-of-scope for a remote desktop client.

If you need to provide access to a web page, there are a couple of things
you can consider:
* Use an existing reverse proxy (Nginx, for example) to provide access to
the web page. You can integrate the proxy into the solution hosting
Guacamole so that you have a single point of access, but you'll need to do
other access control outside of Guacamole).
* Use a remote desktop server of some sort (Windows with RDP, Linux with
xrdp, Linux with VNC) to host a web browser that opens the site that you
want. I've done this recently to help support some legacy Flash
applications using Linux + xrdp and then launch Firefox in Kiosk mode,
which gives you a fairly seamless user experience. You can allow access to
this server with Guacamole, and use authentication pass-through (if using
LDAP/AD) so that users can access the sessions via Guacamole.

-Nick

>

Is there a way to add an HTTP(s) connection as a Connection

[Charles Mccrea]

Hello Forum,

I've been using Guacamole Server as way to allow remote users to access via
SSH and RDP without issue.  But I have a use case whereby I would like to
grant access through Guacamole to a webpage. Is this possible?

Thank you.

Re: Guacamole HTTP header login w/ Authelia

[Nick Couchman]

>
> >   -
> > 'traefik.http.middlewares.authelia.forwardauth.address=
> http://authelia:9091/api/verify?rd=https://login.example.com/'
> >   -
> > 'traefik.http.middlewares.authelia.forwardauth.trustForwardHeader=true'
> >   -
> >
> 'traefik.http.middlewares.authelia.forwardauth.authResponseHeaders=Remote-User,
> > Remote-Groups, Remote-Name,
>
> You then need to follow the manual pages for Guacamole to add the HTTP auth
> extension, and add the 'Remote-User' as a custom header in
> guacamole.properties as follows:
>
>
> > http-auth-header: Remote-User
>
>
Ah, so looks like case sensitivity for the headers, which makes sense.


> I appreciate this may seem trivial to the more experienced on the mailing
> list, but it's taken me quite a while.
>
>
Not at all - thank you for coming back to the list with the solution!

-Nick

Re: Guacamole HTTP header login w/ Authelia

[tomlawesome]

Hello all -- this issue is now actually resolved and is in large part due to
a fundamental misunderstanding on my part about the REMOTE_USER header. 

The following may be of interest to anyone else.. 

I struggled to find a way to see if the correct headers were being passed by
my authentication front end to my docker services (Guacd and Guacamole
included). In my case running the container 'traefik/whoami' and putting it
behind my authentication front end allow me to see all the headers being
passed. 

For anyone wanting to use a similar setup (traefik + authelia in front of
Guacamole), these are the traefik labels to get the headers passed via
authelia, which need to be on the authelia service:


>   -
> 'traefik.http.middlewares.authelia.forwardauth.address=http://authelia:9091/api/verify?rd=https://login.example.com/'
>   -
> 'traefik.http.middlewares.authelia.forwardauth.trustForwardHeader=true'
>   -
> 'traefik.http.middlewares.authelia.forwardauth.authResponseHeaders=Remote-User,
> Remote-Groups, Remote-Name, 

You then need to follow the manual pages for Guacamole to add the HTTP auth
extension, and add the 'Remote-User' as a custom header in
guacamole.properties as follows:


> http-auth-header: Remote-User

I appreciate this may seem trivial to the more experienced on the mailing
list, but it's taken me quite a while. 



--
Sent from: 
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

Re: Guacamole HTTP header login w/ Authelia

[tomlawesome]

Thanks again Nick, very helpful as always. 

I've removed the LDAP authentication backend from my Guac setup, as the
authelia SSO front end uses LDAP anyway, so serves the same purpose.  

I'm using the Docker container, and found a tomcat logs folder in: 
/usr/local/tomcat/logs

The only two with the correct date were catalina.2021-04-21.log and
localhost_access_log.2021-04-21.txt. 

Below are pastes from the output before/after attempting to connect to
Guacmole via HTTP header: 

Before:
https://pb.tomlawson.io/?ecaf618d14d3a76b#DpAQSt6CXrmavVhUG5jFG2EU5i4i9od3nq2c1zFDdW2F
After:
https://pb.tomlawson.io/?100173f1431d46b6#FVk5Q6sDbyUvAakJprUon3aFmjqjCQoZnBigWBzUCAVf

I can't see anything that would suggest an attempted login in the after
paste? But then I can't see any.

The third log is after a manual login via the web UI which is pretty
obviously a login. I would expect to see something similar (even if failed)
in the second/after log? 
Third:
https://pb.tomlawson.io/?6a230b84a51c33a2#FaVU3F2P2yVkd5wkpozMoS5GAvd5txosCnBLuJX8yzYt


All of this to say, I don't think my front end is sending the header, do you
agree? Asking for a second opinion as I'm not familiar with it!



--
Sent from: 
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

Re: Guacamole HTTP header login w/ Authelia

[Nick Couchman]

On Thu, Apr 15, 2021 at 9:30 AM tomlawesome 
wrote:

> Thanks for the reply Nick. I did check the manual but am very new (first
> time
> trying to use them) to using HTTP headers for auth and wasn't entirely sure
> on syntax for guacamole properties if I wanted to use a custom one. Is the
> following correct? I know I don't need to specify anything in
> guacamole.properties for REMOTE_USER but am just using it as syntax example
> for my understanding.
>
> http-auth-header: 
> http-auth-header: REMOTE_USER
>

Yes, so, if you wanted the header SMASHED_AVOCADOS to be used for the user,
you would specify:

http-auth-header: SMASHED_AVOCADOS

and, then, in your identity provider configuration, and, possibly also in
your reverse proxy configuration (if you're using one), you'd need to
specify that header as the one to send and to be passed through.


>
> Also, is there a way I can verify that Guacamole is even seeing the header?
> I appreciate that this is not an traefik mailing list, but I'm not sure if
> Guacamole is receiving the header and not doing anything with it, or if
> traefik's not sending it.
>
>
This should be logged in the Tomcat logs (catalina.out, syslog, journald,
wherever Tomcat gets logged) - it'll log either a successful authentication
for a particular user, or failed anonymous authentication.


> I'm using mariaDB + LDAP for authentication backends
>
>
Note that if you're using LDAP authentication extension in Guacamole, a
successful authentication by the header module will mean that the LDAP
module is not called at all, particularly because the LDAP module requires
that the password of the user logging in is passed through. You'll be able
to see/use connection information from the JDBC module, but not the LDAP
module.

-Nick

Re: Guacamole HTTP header login w/ Authelia

[tomlawesome]

Thanks for the reply Nick. I did check the manual but am very new (first time
trying to use them) to using HTTP headers for auth and wasn't entirely sure
on syntax for guacamole properties if I wanted to use a custom one. Is the
following correct? I know I don't need to specify anything in
guacamole.properties for REMOTE_USER but am just using it as syntax example
for my understanding. 

http-auth-header:  
http-auth-header: REMOTE_USER

Also, is there a way I can verify that Guacamole is even seeing the header?
I appreciate that this is not an traefik mailing list, but I'm not sure if
Guacamole is receiving the header and not doing anything with it, or if
traefik's not sending it.

I'm using mariaDB + LDAP for authentication backends

Cheers,
Tom



--
Sent from: 
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

Re: Guacamole HTTP header login w/ Authelia

[Nick Couchman]

On Wed, Apr 14, 2021 at 9:41 AM tomlawesome 
wrote:

> Hi all,
>
> I am trying to using HTTP headers to login to guac directly after
> authenticating via Authelia. Currently it does not support OpenID
> unfortunately.
>
> I can find very little info in Authelia's docs, but have been tyring to
> find
> a way/figure out how to use the following:
>
>
> https://www.authelia.com/docs/community/using-remote-user-header-for-sso-with-jira.html
>
> And use that HTTP header to log into Guacamole.
>
> Would anybody be able to assist me with:
>
> - How does this verify Guacamole credentials? Does the user/pass have to be
> the same for both services?


Not the password, but the username - if you install the header extension in
Guacamole, as long as the username matches Guacamole will use that to
associate the user with other modules (for example, JDBC). It's really
important with the header module to make sure that the configuration is
secure and that you don't allow unknown/untrusted pages to pass through the
REMOTE_USER header to Guacamole.


>
> - What's the correct syntax to add the header info into
> guacamole.properties
>
>
Unless you want to use a header other than REMOTE_USER, you only need to
install the extension - there's no configuration required. If you want to
use a different header you can use the guacamole.properties to change
that.  It's all documented, here:

http://guacamole.apache.org/doc/gug/header-auth.html

-Nick

Guacamole HTTP header login w/ Authelia

[tomlawesome]

Hi all, 

I am trying to using HTTP headers to login to guac directly after
authenticating via Authelia. Currently it does not support OpenID
unfortunately. 

I can find very little info in Authelia's docs, but have been tyring to find
a way/figure out how to use the following: 

https://www.authelia.com/docs/community/using-remote-user-header-for-sso-with-jira.html

And use that HTTP header to log into Guacamole. 

Would anybody be able to assist me with:

- How does this verify Guacamole credentials? Does the user/pass have to be
the same for both services? 
- What's the correct syntax to add the header info into guacamole.properties

Any help greatly appreciated :)

Cheers,
Tom



--
Sent from: 
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

HTTP tunnel request rejected: No tunnel created

[Michał Kalinowski]

Hello,

I am trying to setup Guacamole connection in my Spring Application. I am 
almost done, but I keep getting the following error:


*/HTTP tunnel request rejected: No tunnel created/*

This is what I see in browser console:

/POST http://localhost:8080/tunnel?connect/

/Error: 404/

(seems like some connect attribute is empty? But how do I set it and 
what should be inside it?)

//

This is how I add the appropiate servlet to my app:

/@Bean//
//    public ServletRegistrationBean 
exampleServletBean() {//
//        ServletRegistrationBean bean = new 
ServletRegistrationBean<>(//

//      new GuacamoleConnector(), "/tunnel/*");//
//        bean.setLoadOnStartup(1);//
//        return bean;//
//    }/

This is how I create a tunnel: (almost exact as in Guacamole guide)

/protected GuacamoleTunnel doConnect(HttpServletRequest request, String 
IP) throws GuacamoleException {/


/ GuacamoleConfiguration config = new GuacamoleConfiguration();//
//        config.setProtocol("vnc");//
//        config.setParameter("hostname", IP);//
//        config.setParameter("port", "5900");//
//        config.setParameter("password", "password");//


//        GuacamoleSocket socket = new ConfiguredGuacamoleSocket(//
//        new InetGuacamoleSocket("example.mydomain.com", 
4822),//

//        config//
//        );/

/}

//        return new SimpleGuacamoleTunnel(socket);/


Javascript on my page is *exact* as in Guacamole guide. Did not change a 
thing.


My docker log:

/guacd[7]: INFO: Creating new client for protocol "vnc"//
//guacd[7]: INFO: Connection ID is "$d0e0811a-1985-4ca8-b37f-c7ca6d67bdad"//
//guacd[618]: INFO:   Cursor rendering: local//
//guacd[618]: INFO:   User "@5925c83e-e209-46b1-bc77-3e295fe6a3eb" 
joined connection "$d0e0811a-1985-4ca8-b37f-c7ca6d67bdad" (1 users now 
present)//

//guacd[618]: ERROR:  User is not responding./

/guacd[626]: INFO:   User "@0b559c19-46b5-48a3-a503-b6cd5c169bd5" 
disconnected (0 users remain)
guacd[626]: INFO:   Last user of connection 
"$06545683-6b86-46f1-893d-e88ea7aea6e8" disconnected

guacd[626]: INFO:   Internal VNC client disconnected/

/
/

And finally the code that invokes the connection:

/@GetMapping(value = "/displayer")//
//    public String goVNC(@RequestParam String IP, HttpServletRequest 
request, Model model)//

//    {//
//        GuacamoleConnector guacConnect = new GuacamoleConnector();//
//        try {//
//            GuacamoleTunnel tunnel = guacConnect.doConnect(request,IP);//
//            return "displayer";//
//        } catch (GuacamoleException e) {//

//            e.printStackTrace();//
//            return "error";//
//        }//

//    }/

(I don't think the HttpServletRequest argument is needed, because 
/doConnect()/ method doesn't do anything with it. Servlet is handled by 
the bean I showed above)


I would appreciate some clue on the case, as I think I am so close to 
making it work!



Michael


P.S. Thank you for help with my previous problem *@Nick Couchman*! 
Worked like a charm.

Re: Parameter token with HTTP header authentication extension

[Yang Yang]

Hi Nick,

Following your guidance, I made some modifications to the  the header module, 
having it look for another header and make that available as a token, but 
failed to get the session id for the record name. Is there anything else I 
should do?

Thanks,
Yang


> On Apr 27, 2020, at 17:30, Yang Yang  wrote:
> 
> Hi Nick,
> 
> I failed to get session id from http header “SessionID” with settings 
> “http-session-id-header: SessionID” in guacamole.properties. Changes I made 
> to guacamole-auth-header extension is as below. Is there anything else I 
> missed? With record name set to ${HHEADER_SESSION_ID}-${GUAC_USERNAME}, I can 
> get the correct user name in the record name,  as 
> ${HHEADER_SESSION_ID}-guacadmin.1.
> 
> #
> diff -Naur 
> guacamole-client-1.1.0/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/AuthenticationProviderService.java
>  
> guacamole-client-1.1.0-session-id/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/AuthenticationProviderService.java
> --- 
> guacamole-client-1.1.0/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/AuthenticationProviderService.java
>   2019-06-24 07:13:11.0 +0800
> +++ 
> guacamole-client-1.1.0-session-id/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/AuthenticationProviderService.java
>2020-04-26 21:34:04.715403123 +0800
> @@ -21,12 +21,15 @@
> 
>  import com.google.inject.Inject;
>  import com.google.inject.Provider;
> +import java.util.Map;
> +import java.util.HashMap;
>  import javax.servlet.http.HttpServletRequest;
>  import org.apache.guacamole.GuacamoleException;
>  import org.apache.guacamole.net.auth.Credentials;
>  import org.apache.guacamole.net.auth.credentials.CredentialsInfo;
>  import 
> org.apache.guacamole.net.auth.credentials.GuacamoleInvalidCredentialsException;
>  import org.apache.guacamole.auth.header.user.AuthenticatedUser;
> +import org.apache.guacamole.token.TokenName;
>  import java.security.Principal;
> 
>  /**
> @@ -34,6 +37,10 @@
>   * AuthenticationProvider implementation.
>   */
>  public class AuthenticationProviderService {
> +/**
> + * The prefix to use when getting http header attribute token.
> + */
> +public static final String HTTP_HEADER_ATTRIBUTE_TOKEN_PREFIX = 
> "HHEADER_";
> 
>  /**
>   * Service for retrieving header configuration information.
> @@ -68,13 +75,26 @@
>  // Pull HTTP header from request if present
>  HttpServletRequest request = credentials.getRequest();
>  if (request != null) {
> +Map tokens = new HashMap<>();
> +
> +// Get the session id from the header configured in 
> guacamole.properties
> +String session_id = 
> request.getHeader(confService.getHttpSessionIdHeader());
> +
> +if (session_id != null) {
> +// Pass session_id to gucamole server as a custom token
> +String tokenName = TokenName.canonicalize("SESSION_ID",
> +HTTP_HEADER_ATTRIBUTE_TOKEN_PREFIX);
> +Object value = session_id;
> +if (value != null)
> +tokens.put(tokenName, value.toString());
> +}
> 
>  // Get the username from the header configured in 
> guacamole.properties
>  String username = 
> request.getHeader(confService.getHttpAuthHeader());
> 
>  if (username != null) {
>  AuthenticatedUser authenticatedUser = 
> authenticatedUserProvider.get();
> -authenticatedUser.init(username, credentials);
> +authenticatedUser.init(username, credentials, tokens);
>  return authenticatedUser;
>  }
> 
> diff -Naur 
> guacamole-client-1.1.0/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/ConfigurationService.java
>  
> guacamole-client-1.1.0-session-id/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/ConfigurationService.java
> --- 
> guacamole-client-1.1.0/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/ConfigurationService.java
>2019-06-24 07:13:11.00000 +0800
> +++ 
> guacamole-client-1.1.0-session-id/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/ConfigurationService.java
> 2020-04-26 21:18:44.196791822 +0800
> @@ -54,4 +54,22 @@
>  );
>  }
> 
> +/**
> + * Returns the header of the HTTP server as configured with
> + * guacamole.properties used for HTTP session id.
> + * By defa

Re: Parameter token with HTTP header authentication extension

[Yang Yang]

Hi Nick,

I failed to get session id from http header “SessionID” with settings 
“http-session-id-header: SessionID” in guacamole.properties. Changes I made to 
guacamole-auth-header extension is as below. Is there anything else I missed? 
With record name set to ${HHEADER_SESSION_ID}-${GUAC_USERNAME}, I can get the 
correct user name in the record name,  as ${HHEADER_SESSION_ID}-guacadmin.1.

#
diff -Naur 
guacamole-client-1.1.0/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/AuthenticationProviderService.java
 
guacamole-client-1.1.0-session-id/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/AuthenticationProviderService.java
--- 
guacamole-client-1.1.0/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/AuthenticationProviderService.java
  2019-06-24 07:13:11.0 +0800
+++ 
guacamole-client-1.1.0-session-id/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/AuthenticationProviderService.java
   2020-04-26 21:34:04.715403123 +0800
@@ -21,12 +21,15 @@

 import com.google.inject.Inject;
 import com.google.inject.Provider;
+import java.util.Map;
+import java.util.HashMap;
 import javax.servlet.http.HttpServletRequest;
 import org.apache.guacamole.GuacamoleException;
 import org.apache.guacamole.net.auth.Credentials;
 import org.apache.guacamole.net.auth.credentials.CredentialsInfo;
 import 
org.apache.guacamole.net.auth.credentials.GuacamoleInvalidCredentialsException;
 import org.apache.guacamole.auth.header.user.AuthenticatedUser;
+import org.apache.guacamole.token.TokenName;
 import java.security.Principal;

 /**
@@ -34,6 +37,10 @@
  * AuthenticationProvider implementation.
  */
 public class AuthenticationProviderService {
+/**
+ * The prefix to use when getting http header attribute token.
+ */
+public static final String HTTP_HEADER_ATTRIBUTE_TOKEN_PREFIX = "HHEADER_";

 /**
  * Service for retrieving header configuration information.
@@ -68,13 +75,26 @@
     // Pull HTTP header from request if present
 HttpServletRequest request = credentials.getRequest();
 if (request != null) {
+Map tokens = new HashMap<>();
+
+// Get the session id from the header configured in 
guacamole.properties
+String session_id = 
request.getHeader(confService.getHttpSessionIdHeader());
+
+if (session_id != null) {
+// Pass session_id to gucamole server as a custom token
+String tokenName = TokenName.canonicalize("SESSION_ID",
+HTTP_HEADER_ATTRIBUTE_TOKEN_PREFIX);
+Object value = session_id;
+if (value != null)
+tokens.put(tokenName, value.toString());
+}

 // Get the username from the header configured in 
guacamole.properties
 String username = 
request.getHeader(confService.getHttpAuthHeader());

 if (username != null) {
 AuthenticatedUser authenticatedUser = 
authenticatedUserProvider.get();
-authenticatedUser.init(username, credentials);
+authenticatedUser.init(username, credentials, tokens);
 return authenticatedUser;
 }

diff -Naur 
guacamole-client-1.1.0/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/ConfigurationService.java
 
guacamole-client-1.1.0-session-id/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/ConfigurationService.java
--- 
guacamole-client-1.1.0/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/ConfigurationService.java
   2019-06-24 07:13:11.0 +0800
+++ 
guacamole-client-1.1.0-session-id/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/ConfigurationService.java
2020-04-26 21:18:44.196791822 +0800
@@ -54,4 +54,22 @@
 );
 }

+/**
+ * Returns the header of the HTTP server as configured with
+ * guacamole.properties used for HTTP session id.
+ * By default, this will be "SESSION_ID".
+ *
+ * @return
+ * The header used for HTTP session id, as configured with
+ * guacamole.properties.
+ *
+ * @throws GuacamoleException
+ * If guacamole.properties cannot be parsed.
+ */
+public String getHttpSessionIdHeader() throws GuacamoleException {
+return environment.getProperty(
+HTTPHeaderGuacamoleProperties.HTTP_SESSION_ID_HEADER,
+"SESSION_ID"
+);
+}
 }
diff -Naur 
guacamole-client-1.1.0/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/HTTPHeaderGuacamoleProperties.java
 
guacamole-client-1.1.0-session-id/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/HTTPHeaderGuacamoleProperties.java
--- 
guacamole

Re: Parameter token with HTTP header authentication extension

[Yang Yang]

Very helpful info, Nick! Thank you very much!

Thanks,
Yang

> On Apr 23, 2020, at 03:36, Nick Couchman  wrote:
> 
> On Wed, Apr 22, 2020 at 5:46 AM Yang Yang  wrote:
> Hi,
> 
> I am looking to use the string in certain HTTP header as a session id, and 
> name the record of the session. Is there any parameter token with HTTP header 
> authentication extension I can use? If not, could you help to tell what I 
> should do to customize the HTTP header authentication extension to work in 
> this way? 
> 
> What I really want to achieve is have a unique id for each session record 
> file that I can generate by myself. Do you have any other solution?
> 
> 
> The only thing that the header module currently passes through is the header 
> that identifies the user.  You could easily add another value to this by 
> modifying the following code:
> 
> https://github.com/apache/guacamole-client/blob/f2405d936379b62553c25cf13270587e0c9feff1/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/AuthenticationProviderService.java#L65-L86
>  
> <https://github.com/apache/guacamole-client/blob/f2405d936379b62553c25cf13270587e0c9feff1/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/AuthenticationProviderService.java#L65-L86>
> 
> That is where the header module extracts the header and makes it available.  
> You could tweak that code and have it look for another header of your 
> specification that would be passed through, and make that available as a 
> token.
> 
> Alternatively, Guacamole also has the ${GUAC_DATE} and ${GUAC_TIME} tokens, 
> so if you need to put together something that uniquely identifies the user 
> (i.e. for recording purposes) you could use a combination of tokens, like:
> 
> ${GUAC_USERNAME}-${GUAC_DATE}-${GUAC_TIME}
> 
> -Nick

Re: Parameter token with HTTP header authentication extension

[Nick Couchman]

On Wed, Apr 22, 2020 at 5:46 AM Yang Yang  wrote:

> Hi,
>
> I am looking to use the string in certain HTTP header as a session id, and
> name the record of the session. Is there any parameter token with HTTP
> header authentication extension I can use? If not, could you help to tell
> what I should do to customize the HTTP header authentication extension to
> work in this way?
>
> What I really want to achieve is have a unique id for each session record
> file that I can generate by myself. Do you have any other solution?
>
>
The only thing that the header module currently passes through is the
header that identifies the user.  You could easily add another value to
this by modifying the following code:

https://github.com/apache/guacamole-client/blob/f2405d936379b62553c25cf13270587e0c9feff1/extensions/guacamole-auth-header/src/main/java/org/apache/guacamole/auth/header/AuthenticationProviderService.java#L65-L86

That is where the header module extracts the header and makes it
available.  You could tweak that code and have it look for another header
of your specification that would be passed through, and make that available
as a token.

Alternatively, Guacamole also has the ${GUAC_DATE} and ${GUAC_TIME} tokens,
so if you need to put together something that uniquely identifies the user
(i.e. for recording purposes) you could use a combination of tokens, like:

${GUAC_USERNAME}-${GUAC_DATE}-${GUAC_TIME}

-Nick

Parameter token with HTTP header authentication extension

[Yang Yang]

Hi,

I am looking to use the string in certain HTTP header as a session id, and name 
the record of the session. Is there any parameter token with HTTP header 
authentication extension I can use? If not, could you help to tell what I 
should do to customize the HTTP header authentication extension to work in this 
way? 

What I really want to achieve is have a unique id for each session record file 
that I can generate by myself. Do you have any other solution?

Thanks,
Yang
-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

Re: HTTP protocol

[Nick Couchman]

On Tue, Jan 7, 2020 at 3:15 AM Vieri  wrote:

>
>
> On Sunday, January 5, 2020, 4:16:46 PM GMT+1, Nick Couchman <
> vn...@apache.org> wrote:
> >
> > Mostly that Guacamole is designed to be a web-based remote desktop
> client, not a full VPN client, and we're interested in keeping the
> > scope contained.
>
> Understandable. However, I'm still not sure how the commercial product I
> mentioned earlier does it. Even though the provider mentions "SSL-VPN" in
> its on-line guide, I doubt it can be a "real" VPN client as it would imply
> admin privs on the client (supposedly, nothing is supposed to be run as
> root/admin). So that's why I'm wondering (cannot confirm it yet) if the
> provider has implemented some sort of HTML to image rendering, or if it's
> "merely" a redirection to a reverse proxy.


Obviously it's hard to know exactly what the commercial product is using -
could be something open source (happens quite frequently), but also could
be something the wrote themselves.  And, no, there is no VPN Client - that
is, indeed, the point of such web-based "SSL VPN" portals - that you don't
have to have the client.


> If that were the case then I already have my Apache HTTP service
> configured for reverse proxy (I also have a few Squid instances for other
> HTTP services). So sure, I could merely "extend" Guacamole to display URL
> connection objects when the user logs in, alongside RDP, telnet, ssh and
> VNC connections. The problem I'm facing is that for some reason I don't
> fully share, I am asked to create a single portal and a single URL, eg.
> https://guac.domain.org/ from which the users can then connect to
> whichever internal service. Since I've managed to configure fully
> functional reverse proxies with Apache HTTP (but had redirection issues
> with Squid), I would need to use at least a different port or domain. I
> guess what I really need to do is learn how to configure a reverse proxy
> with Apache Tomcat and try to use the same port for that. It would look
> something like this:
>
> https://guac.domain.org/proxy1 -> internal HTTP service 1
>
> https://guac.domain.org/proxy2 -> internal HTTP service 2
>
> https://guac.domain.org/proxy3 -> internal HTTP service 3
>
> and so no.
> And of course, https://guac.domain.org/ would have to be the guacamole
> web client.
>

I think you've recently figured out how to do this :-).  You should also be
able to configure something like Nginx such that you could do:

https://guac.domain.org/proxy?uri=https%3A%2F%2Fmy.super.secret.server.local%2Fpath

Obviously if you provide that kind of functionality you want to be very
careful that 1) you're authenticating users properly, and 2) that you limit
what URLs and paths people can try to access from that server such that
sensitive sites, data, etc., are not exposed outside the boundaries of your
network.


>
>  I'm new to Apache Tomcat so I guess I have a lot of homework to do.
>
> > First, i share your desire to do as much as possible with Open Source
> software, and I routinely have to fight the battle of why to stick
> > with open source rather than spending money on a commercial product.
>
> It's not just a question of money. It is also because OSS is extremely
> flexible, and usually adapts faster and better. Customization is the key.
> Sure, development can be a bit chaotic sometimes (à la freerdp lib...), but
> I guess that's part of the fun.
>
>
I totally agree.

-Nick

Re: HTTP protocol

[Vieri]

On Sunday, January 5, 2020, 4:16:46 PM GMT+1, Nick Couchman  
wrote: 
>
> Mostly that Guacamole is designed to be a web-based remote desktop client, 
> not a full VPN client, and we're interested in keeping the 
> scope contained.

Understandable. However, I'm still not sure how the commercial product I 
mentioned earlier does it. Even though the provider mentions "SSL-VPN" in its 
on-line guide, I doubt it can be a "real" VPN client as it would imply admin 
privs on the client (supposedly, nothing is supposed to be run as root/admin). 
So that's why I'm wondering (cannot confirm it yet) if the provider has 
implemented some sort of HTML to image rendering, or if it's "merely" a 
redirection to a reverse proxy. If that were the case then I already have my 
Apache HTTP service configured for reverse proxy (I also have a few Squid 
instances for other HTTP services). So sure, I could merely "extend" Guacamole 
to display URL connection objects when the user logs in, alongside RDP, telnet, 
ssh and VNC connections. The problem I'm facing is that for some reason I don't 
fully share, I am asked to create a single portal and a single URL, eg. 
https://guac.domain.org/ from which the users can then connect to whichever 
internal service. Since I've managed to configure fully functional reverse 
proxies with Apache HTTP (but had redirection issues with Squid), I would need 
to use at least a different port or domain. I guess what I really need to do is 
learn how to configure a reverse proxy with Apache Tomcat and try to use the 
same port for that. It would look something like this:

https://guac.domain.org/proxy1 -> internal HTTP service 1

https://guac.domain.org/proxy2 -> internal HTTP service 2

https://guac.domain.org/proxy3 -> internal HTTP service 3

and so no.
And of course, https://guac.domain.org/ would have to be the guacamole web 
client.

 I'm new to Apache Tomcat so I guess I have a lot of homework to do.

> First, i share your desire to do as much as possible with Open Source 
> software, and I routinely have to fight the battle of why to stick 
> with open source rather than spending money on a commercial product. 

It's not just a question of money. It is also because OSS is extremely 
flexible, and usually adapts faster and better. Customization is the key. Sure, 
development can be a bit chaotic sometimes (à la freerdp lib...), but I guess 
that's part of the fun.

Big thanks for the support.

Vieri

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

Re: HTTP protocol

[Nick Couchman]

On Sun, Jan 5, 2020 at 6:54 AM Vieri  wrote:

> Hi again,
>
> I know the Guacamole devs don't want to implement a "VPN-like" web portal
> to access other protocols such as HTTP/HTTPS and FTP (discussed before)...


Mostly that Guacamole is designed to be a web-based remote desktop client,
not a full VPN client, and we're interested in keeping the scope contained.


> ...but I'd like to know if anyone here has any thoughts/experience
> regarding a guacamole-like portal such as:
>
>
> https://help.fortinet.com/fmgr/50hlp/56/5-6-2/FMG-FAZ/1300_VPN_Manager/1200_SSL_VPN/0410_Pre%20defined%20bookmarks.htm
>
> This commercial product offers basically the same features as Guacamole
> (except for the fact that telnet, vnc and rdp require a plug-in which I
> dislike) with the added support for HTTP/HTTPS and FTP services.
>
> I'm struggling to keep using open-source projects whenever possible, but
> not everyone is on my side :-(. I'd like to keep using Guacamole (because
> it simply works great), and for that I'd need to argue why. The only
> missing piece for me is really HTTP, and I'm wondering how this commercial
> product is implementing it. As previously commented in this thread, it's
> hard to imagine that it's implemented as "HTML to image rendering" (but
> possible). It may also be simply a reverse proxy setup (which could be
> implemented with other open-source projects), but it doesn't seem to be.
> Does anyone have experience with this or similar products (regarding HTTP)?
>
>
First, i share your desire to do as much as possible with Open Source
software, and I routinely have to fight the battle of why to stick with
open source rather than spending money on a commercial product.  I'm always
happy to help architect solutions that leverage open source software, even
if they're outside the scope of this project.

Regarding the ability to have an HTTP(S) portal implemented alongside
Guacamole, I think this is possible using one of a couple of different
options.  In doing some past research on this, I believe Nginx had some
ability to configure itself as a Reverse Proxy that can use parameters to
allow access for particular site.  Squid may also have the capability to do
some of these things.  I've never personally configured or implemented it,
but I believe it's possible.

Tying it all together into a single solution is going to take some work - I
don't know of anything out there, today, that has it all built in, but all
of the components are there and it just needs to be collected into a single
solution.  It will probably take some development work to bring it all
together, but I think it's possible.  Implementing a portal of sorts that
will bring it into a single view and allow you to publish URLs that can
then be reverse-proxied back through a portal into something else.

-Nick

Re: HTTP protocol

[Vieri]

On Sunday, January 5, 2020, 12:54:46 PM GMT+1, Vieri 
 wrote: 
>
> https://help.fortinet.com/fmgr/50hlp/56/5-6-2/FMG-FAZ/1300_VPN_Manager/1200_SSL_VPN/0410_Pre%20defined%20bookmarks.htmPredefined
>  bookmarks

Sorry, the correct link is:
https://help.fortinet.com/fmgr/50hlp/56/5-6-2/FMG-FAZ/1300_VPN_Manager/1200_SSL_VPN/0410_Pre%20defined%20bookmarks.htm

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

HTTP protocol

[Vieri]

Hi again,

I know the Guacamole devs don't want to implement a "VPN-like" web portal to 
access other protocols such as HTTP/HTTPS and FTP (discussed before), but I'd 
like to know if anyone here has any thoughts/experience regarding a 
guacamole-like portal such as:

https://help.fortinet.com/fmgr/50hlp/56/5-6-2/FMG-FAZ/1300_VPN_Manager/1200_SSL_VPN/0410_Pre%20defined%20bookmarks.htmPredefined
 bookmarks

This commercial product offers basically the same features as Guacamole (except 
for the fact that telnet, vnc and rdp require a plug-in which I dislike) with 
the added support for HTTP/HTTPS and FTP services. 

I'm struggling to keep using open-source projects whenever possible, but not 
everyone is on my side :-(. I'd like to keep using Guacamole (because it simply 
works great), and for that I'd need to argue why. The only missing piece for me 
is really HTTP, and I'm wondering how this commercial product is implementing 
it. As previously commented in this thread, it's hard to imagine that it's 
implemented as "HTML to image rendering" (but possible). It may also be simply 
a reverse proxy setup (which could be implemented with other open-source 
projects), but it doesn't seem to be. Does anyone have experience with this or 
similar products (regarding HTTP)?

I am trying to make a custom extension where I add URLs to my guacamole portal 
which simply point to Apache HTTPS reverse proxies. However, I'm not sure this 
solution competes effectively with the commercial product I've cited.

Any ideas are very welcome.

Vieri

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

Re: Combining HTTP Header with other Auth Modules

[Nick Couchman]

On Mon, Dec 9, 2019 at 1:34 PM Justin Phelps  wrote:

> I'm currently struggling to figure out how to configure guacamole properly
> given my authentication situation.
>
> I have an Apache proxy setup in front of guacamole, and I use an Apache
> module to handle authentication of the incoming users. This provides a
> collection of HTTP Headers that can be used for identification of the user.
> The proxy also doesn't allow any unauthenticated users to access guacamole
> directly.
>
> The assumption here is if a user has successfully authenticated, they have
> access to *all* the connections configured in the user-mapper.xml file.
>
>
The user-mapper.xml file does not "stack" with the other authentication
modules in the same way, so you cannot use this module in combination with
other authentication modules.  It is designed to be a very simple way to
test that your install is working correctly, but is not really something
that scales well for larger use-cases.

If you need to combine the header module with some other module for storing
connections, the most common and probably easiest thing to do is to use the
JDBC module to store connections.  Aside from that, you could either write
your own module for storing the connections, or Mike has one that takes
JSON input, I believe, for facilitating pulling in connection data that way
without having to set up a database.

-Nick

>

Combining HTTP Header with other Auth Modules

[Justin Phelps]

I'm currently struggling to figure out how to configure guacamole properly
given my authentication situation.

I have an Apache proxy setup in front of guacamole, and I use an Apache
module to handle authentication of the incoming users. This provides a
collection of HTTP Headers that can be used for identification of the user.
The proxy also doesn't allow any unauthenticated users to access guacamole
directly.

The assumption here is if a user has successfully authenticated, they have
access to *all* the connections configured in the user-mapper.xml file.

Without the NoAuth plugin, I'm having a hard time figuring out how to say:

Given an authenticated user (as per the Header), give them access to all
connections.

Anyone have tips?
--
Justin Phelps
www.onitato.com
210.560.3124

http://www.linkedin.com/in/linuturk

Re: HTTP protocol

[Nick Couchman]

>
> In the simplest of solutions, the Guacamole Client would merely show extra
> connections as href links. That would only require creating an extra "http
> object" alongside the already existing VNC, RDP, SSH, TELNET objects. In
> other words, one would create the http, vnc, rdp, etc., definitions in
> LDAP, MySQL, plain text file, and once the user logs into Guacamole, he/she
> would see these connections.
> From a firewall/VPN point of view, this solution is awful as it does not
> tunnel the connection, but on the other hand user experience is improved.
> So this first modification isn't really a VPN or remote access gateway...
> It's just a way of adding more objects/connection types, but without the
> image rendering.
> So it should be a piece of cake... If it's not useful to the rest of the
> community then I'll try to do as you suggest and customize the Guacamole
> Client code.
>
>
This is something you could implement within a custom extension using the
ability to modify the user interface and decorate database items within the
environment.  You can see the following page for more information on
extending Guacamole through custom authentication modules.

http://guacamole.apache.org/doc/gug/guacamole-ext.html

-Nick

Re: HTTP protocol

[Vieri]

On Tuesday, December 3, 2019, 9:45:04 PM GMT+1, Nick Couchman 
 wrote: 
> 
> Yes, I understand what you are trying to do by creating a central location 
> for a sort of VPN or remote access gateway.  Again, while 
> Guacamole can be a part of such a solution, we (the project) has determined 
> that we do not intend to take the Guacamole project in that 
> direction.  You are certainly welcome to take the code yourself and customize 
> it however you like - either modifying the Guacamole Client 
> code to do this, or using the Guacamole Common code to build your own remote 
> gateway platform.

In the simplest of solutions, the Guacamole Client would merely show extra 
connections as href links. That would only require creating an extra "http 
object" alongside the already existing VNC, RDP, SSH, TELNET objects. In other 
words, one would create the http, vnc, rdp, etc., definitions in LDAP, MySQL, 
plain text file, and once the user logs into Guacamole, he/she would see these 
connections.
>From a firewall/VPN point of view, this solution is awful as it does not 
>tunnel the connection, but on the other hand user experience is improved.
So this first modification isn't really a VPN or remote access gateway... It's 
just a way of adding more objects/connection types, but without the image 
rendering.
So it should be a piece of cake... If it's not useful to the rest of the 
community then I'll try to do as you suggest and customize the Guacamole Client 
code.

Thanks for the great project!

Vieri

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

Re: HTTP protocol

[Nick Couchman]

On Tue, Dec 3, 2019 at 5:27 AM Vieri  wrote:

> Sure, I could use Squid as a reverse proxy. However, it would be "neat" to
> force users to log into the Guacamole portal so that they can see their
> usual services as icons (ssh, telnet, vnc, rdp) but also some internal
> HTTP(S) services. These HTTP(S) services could be full-fledged reverse
> proxies (eg. Squid) that forward to internal peers. So, not being an expert
> in HTTP proxying, could Guacamole "simply tunnel" HTTP requests/replies to
> and from clients and whatever reverse proxies are in the private network?
> Or would it only allow a redirection (or, simply put, an href link that
> would require opening firewalled ports or hosts)?
>
>
Yes, I understand what you are trying to do by creating a central location
for a sort of VPN or remote access gateway.  Again, while Guacamole can be
a part of such a solution, we (the project) has determined that we do not
intend to take the Guacamole project in that direction.  You are certainly
welcome to take the code yourself and customize it however you like -
either modifying the Guacamole Client code to do this, or using the
Guacamole Common code to build your own remote gateway platform.

-Nick

Re: HTTP protocol

[Vieri]

On Tuesday, December 3, 2019, 1:19:48 AM GMT+1, Nick Couchman 
 wrote: 
>
> Adding support for HTTP(S) might be doable, however it isn't as 
> straight-forward as it seems.  It would involve considerable work on the 
> guacd side to attempt to render the web pages and then send images of those 
> pages across.

I understand this must be very complex.

> The alternative to doing that rendering in guacd is just to have the 
> Guacamole system tunnel the HTTP(S) connection over the HTTP(S) 
> connection used for the other Guacamole traffic.  However, if you're going to 
> do this, why not just use one of the existing reverse proxy 
> configurations out there?  Guacamole can certainly be part of such a solution 
> to handle the remote desktop protocols, but you'll need to 
> find something else to do the HTTP(S) tunneling.

Sure, I could use Squid as a reverse proxy. However, it would be "neat" to 
force users to log into the Guacamole portal so that they can see their usual 
services as icons (ssh, telnet, vnc, rdp) but also some internal HTTP(S) 
services. These HTTP(S) services could be full-fledged reverse proxies (eg. 
Squid) that forward to internal peers. So, not being an expert in HTTP 
proxying, could Guacamole "simply tunnel" HTTP requests/replies to and from 
clients and whatever reverse proxies are in the private network? Or would it 
only allow a redirection (or, simply put, an href link that would require 
opening firewalled ports or hosts)?

Thanks,

Vieri

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org

Re: HTTP protocol

[Nick Couchman]

On Mon, Dec 2, 2019 at 9:36 AM Vieri  wrote:

> Hi,
>
> I was wondering if Guacamole could also support the HTTP protocol. The
> idea is that a user can connect to the Guacamole portal, and from there
> connect to an internal HTTP server whose communication would be tunneled
> through Guacamole (HTTPS).
>

It possibly *could* be done; however, this has been discussed in the past,
and it has been determined that such support is out of scope for this
project.  Guacamole is a client-less remote desktop gateway, but is not
designed to be a complete VPN/Gateway solution.  See:

https://issues.apache.org/jira/browse/GUACAMOLE-57


>
> I know this is usually the job of a reverse proxy, but it's not always
> trivial.
> In my case, the "internal HTTP server" sends HTTP redirects to the client
> (to non-HTTPS urls), and this breaks  the reverse proxy user experience...
>
>
Yes, and Guacamole can be used in conjunction with such solutions to create
an overall client-less VPN/gateway solution, but itself does not support
HTTP(S), nor is it something we are open to putting into the project.


> I find the Guacamole UI to be simple and easy. I was wondering if it were
> easy to add support for HTTP.
>

We appreciate that :-).  Adding support for HTTP(S) might be doable,
however it isn't as straight-forward as it seems.  It would involve
considerable work on the guacd side to attempt to render the web pages and
then send images of those pages across.  Doing this in a way that gives
people the look and feel, and interaction, they expect from a web page
would be challenging.  Furthermore, you'd likely run into some issues with
differences in rendering as expected based on the difference between guacd
attempting to do that with a library vs. the browser on the user screen.
Again, doable - maybe - but not easy, and, out of scope.

The alternative to doing that rendering in guacd is just to have the
Guacamole system tunnel the HTTP(S) connection over the HTTP(S) connection
used for the other Guacamole traffic.  However, if you're going to do this,
why not just use one of the existing reverse proxy configurations out
there?  Guacamole can certainly be part of such a solution to handle the
remote desktop protocols, but you'll need to find something else to do the
HTTP(S) tunneling.

-Nick

HTTP protocol

[Vieri]

Hi,
I was wondering if Guacamole could also support the HTTP protocol. The idea is 
that a user can connect to the Guacamole portal, and from there connect to an 
internal HTTP server whose communication would be tunneled through Guacamole 
(HTTPS).
I know this is usually the job of a reverse proxy, but it's not always 
trivial.In my case, the "internal HTTP server" sends HTTP redirects to the 
client (to non-HTTPS urls), and this breaks  the reverse proxy user 
experience...
I find the Guacamole UI to be simple and easy. I was wondering if it were easy 
to add support for HTTP.
Thanks,
Vieri

Re: Can guacamole record web application through http/s protocol?

[xiaochao]

Thanks a lot!!!



--
Sent from: 
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

Re: Can guacamole record web application through http/s protocol?

[Nick Couchman]

On Thu, Apr 18, 2019 at 10:28 AM xiaochao  wrote:

> "There are many products that already accomplish these goals without
> actually
> recording the exact screens the user is seeing." Could you give me some
> recommendation? Thanks！！
>
>
Palo Alto Networks
Barracuda NgFirewall
Juniper
Untangle
CacheGuard
pfSense (Squid)
Squid
mitmproxy

The first few are commercial products.  For open source solutions, Squid is
probably the most common and is integrated with many other products.  It
can do both forward and reverse proxying.

-Nick

Re: Can guacamole record web application through http/s protocol?

[xiaochao]

"There are many products that already accomplish these goals without actually
recording the exact screens the user is seeing." Could you give me some
recommendation? Thanks！！



--
Sent from: 
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

Re: Can guacamole record web application through http/s protocol?

[Nick Couchman]

On Wed, Apr 17, 2019 at 4:49 PM xiaochao  wrote:

> Thanks for your reply. "I think this would be a killer addition."
>

You're certainly welcome to use the Guacamole code to build your own
solution that includes this, but the Guacamole Project will not be adding
it, as it is considered out-of-scope for the goals of our project.


> "There are plenty of other software products out there that do this", but I
> do really wonder which one can record the screen?
>

Why do you care to have the actual screenshots/images of the browsing
session recorded?  Usually for monitoring web traffic it is sufficient to
just record the URLs that users visit, and any data that is passed between
the user and the web server (either up- or down-loads).  There are many
products that already accomplish these goals without actually recording the
exact screens the user is seeing.

-Nick

Re: Can guacamole record web application through http/s protocol?

[xiaochao]

Thanks for your reply. "I think this would be a killer addition."
"There are plenty of other software products out there that do this", but I
do really wonder which one can record the screen?



--
Sent from: 
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

Re: Can guacamole record web application through http/s protocol?

[Nick Couchman]

On Wed, Apr 17, 2019 at 4:15 PM xiaochao  wrote:

> Guacd support protocol like vnc and rdp. Is it possible it also support
> html?
>

No, the project has made a decision not to try to implement HTTP(S) proxy
support.  There are plenty of other software products out there that do
this, and Guacamole can be used in combination with those, but the purpose
of Guacamole is to provide support for common remote desktop protocols, not
proxy all types of traffic.  See the following JIRA issue for further
discussion:

https://issues.apache.org/jira/browse/GUACAMOLE-57



> and Guacamole also support web application screen record?
>
>
Guacamole supports recording sessions for all of the protocols that it
supports, and playing them back or encoding them into a video.

-Nick

Can guacamole record web application through http/s protocol?

[xiaochao]

Guacd support protocol like vnc and rdp. Is it possible it also support html?
and Guacamole also support web application screen record?

Best regards!



--
Sent from: 
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

Re: HTTP header auth with groups

[Nick Couchman]

On Wed, Apr 3, 2019 at 8:45 AM Will Payne  wrote:

>
> I'm assuming groups should work with users authenticated via HTTP
> headers?
>
> If I put a user in a group and allow that group access to a connection,
> the user cannot see the connection.
>
> Is this a bug?
>

Not really a bug, no, but it is something we are looking at changing.  The
issue is described, here:

https://issues.apache.org/jira/browse/GUACAMOLE-696

Basically, the way it was (intentionally) implemented in 1.0.0, group
membership is *only* factored in from the module which logs the user in.
Since the header module does not actually process or support groups, users
logged in with the header module will not inherit any group membership or
permissions based on the groups.

This is slated to be addressed in 1.1.0 - I have a pull request out for it,
and hopefully the behavior will get a tweak to work a little more as people
seem to expect it to.

-Nick

HTTP header auth with groups

[Will Payne]

I'm assuming groups should work with users authenticated via HTTP 
headers?


If I put a user in a group and allow that group access to a connection, 
the user cannot see the connection.


Is this a bug?


I also noticed that if a user is granted access to a connection both in 
their user settings and via a group, attempting to use the connection 
throws a connection error and the following appears in the log :


03-Apr-2019 12:37:02.215 SEVERE [http-nio-8080-exec-5] 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error 
reading request, ignored
 org.apache.ibatis.exceptions.TooManyResultsException: Expected one 
result (or null) to be returned by selectOne(), but found: 2
at 
org.apache.ibatis.session.defaults.DefaultSqlSession.selectOne(DefaultSqlSession.java:81)

at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.ibatis.session.SqlSessionManager$SqlSessionInterceptor.invoke(SqlSessionManager.java:357)

at com.sun.proxy.$Proxy33.selectOne(Unknown Source)
at 
org.apache.ibatis.session.SqlSessionManager.selectOne(SqlSessionManager.java:166)
at 
org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:83)

at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:59)
at com.sun.proxy.$Proxy114.selectOne(Unknown Source)
at 
org.apache.guacamole.auth.jdbc.permission.ModeledObjectPermissionService.hasPermission(ModeledObjectPermissionService.java:171)
at 
org.apache.guacamole.auth.jdbc.permission.ObjectPermissionSet.hasPermission(ObjectPermissionSet.java:103)
at 
org.apache.guacamole.auth.jdbc.base.ModeledDirectoryObjectService.hasObjectPermission(ModeledDirectoryObjectService.java:175)
at 
org.apache.guacamole.auth.jdbc.connection.ConnectionService.connect(ConnectionService.java:514)
at 
org.apache.guacamole.auth.jdbc.connection.ModeledConnection.connect(ModeledConnection.java:263)
at 
org.apache.guacamole.tunnel.TunnelRequestService.createConnectedTunnel(TunnelRequestService.java:219)
at 
org.apache.guacamole.tunnel.TunnelRequestService.createTunnel(TunnelRequestService.java:393)
at 
org.apache.guacamole.tunnel.websocket.RestrictedGuacamoleWebSocketTunnelEndpoint.createTunnel(RestrictedGuacamoleWebSocketTunnelEndpoint.java:113)
at 
org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint.onOpen(GuacamoleWebSocketTunnelEndpoint.java:200)
at 
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:133)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:852)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

at java.lang.Thread.run(Thread.java:748)

(This is the 1.0.0 docker image)

W

答复: POST /guacamole/api/tokens HTTP/1.1" 500

[Oliver . Zhang]

I got it.because  the guacamole_user privilegees  is not  enough.



mysql> CREATE DATABASE guacamole_db;

Query OK, 1 row affected (0.00 sec)



mysql> CREATE USER 'guacamole_user'@'localhost' IDENTIFIED BY 'some_password';

Query OK, 0 rows affected (0.00 sec)



mysql> GRANT SELECT,INSERT,UPDATE,DELETE ON guacamole_db.* TO 
'guacamole_user'@'localhost';

Query OK, 0 rows affected (0.00 sec)



mysql> FLUSH PRIVILEGES;

Query OK, 0 rows affected (0.02 sec)





发件人: Mike Jumper [mailto:mjum...@apache.org]
发送时间: 2019年4月1日 21:25
收件人: user@guacamole.apache.org
主题: Re: POST /guacamole/api/tokens HTTP/1.1" 500

On Mon, Apr 1, 2019, 06:13 Oliver.Zhang 
mailto:zhangjianp...@hikvision.com>> wrote:
my guacamole server  deploy in the vm the ip is 10.66.204.10, I cloned a vm 
from 10.66.204.10 and set the ip is 10.66.204.13 for the new cloned vm
i stop the mysql in the new cloned vm, and modify mysql-hostname: to 
10.66.204.10 in the guacamole.properties, the start the guacamole guacd and 
tomcat
why it still access to mysql 10.66.204.13 and not the 10.66.204.10?

If the logs show that access is being denied to the MySQL user at 10.66.204.13, 
it is because that is the IP address of the Guacamole server relative to the 
MySQL server.

If you are expecting otherwise, I suggest rechecking the configuration of your 
VM and network settings. According to your logs, reality doesn't agree with 
that expectation.

- Mike



CONFIDENTIALITY NOTICE:

This electronic message is intended to be viewed only by the individual or 
entity to whom it is addressed. It may contain information that is privileged, 
confidential and exempt from disclosure under applicable law. Any 
dissemination, distribution or copying of this communication is strictly 
prohibited without our prior permission. If the reader of this message is not 
the intended recipient, or the employee or agent responsible for delivering the 
message to the intended recipient, or if you have received this communication 
in error, please notify us immediately by return e-mail and delete the original 
message and any copies of it from your computer system. For further information 
about Hikvision company. please see our website at 
www.hikvision.com<http://www.hikvision.com>

Re: POST /guacamole/api/tokens HTTP/1.1" 500

[Mike Jumper]

On Mon, Apr 1, 2019, 06:13 Oliver.Zhang  wrote:

> my guacamole server  deploy in the vm the ip is 10.66.204.10, I cloned a
> vm from 10.66.204.10 and set the ip is 10.66.204.13 for the new cloned vm
>
> i stop the mysql in the new cloned vm, and modify mysql-hostname: to
> 10.66.204.10 in the guacamole.properties, the start the guacamole guacd
> and tomcat
>
> why it still access to mysql 10.66.204.13 and not the 10.66.204.10?
>

If the logs show that access is being denied to the MySQL user at
10.66.204.13, it is because that is the IP address of the Guacamole server
relative to the MySQL server.

If you are expecting otherwise, I suggest rechecking the configuration of
your VM and network settings. According to your logs, reality doesn't agree
with that expectation.

- Mike

答复: POST /guacamole/api/tokens HTTP/1.1" 500

[Oliver . Zhang]

my guacamole server  deploy in the vm the ip is 10.66.204.10, I cloned a vm 
from 10.66.204.10 and set the ip is 10.66.204.13 for the new cloned vm
i stop the mysql in the new cloned vm, and modify mysql-hostname: to 
10.66.204.10 in the guacamole.properties, the start the guacamole guacd and 
tomcat
why it still access to mysql 10.66.204.13 and not the 10.66.204.10?


发件人: Nick Couchman [mailto:vn...@apache.org]
发送时间: 2019年4月1日 20:58
收件人: user@guacamole.apache.org
主题: Re: POST /guacamole/api/tokens HTTP/1.1" 500



On Mon, Apr 1, 2019 at 8:47 AM Oliver.Zhang 
mailto:zhangjianp...@hikvision.com>> wrote:
The tomcat error log is :
### Error querying database.  Cause: java.sql.SQLException: Access denied for 
user 'guacamole_user'@'10.66.204.13' (using password: YES)
### The error may exist in org/apache/guacamole/auth/jdbc/user/UserMapper.xml
### The error may involve 
org.apache.guacamole.auth.jdbc.user.UserMapper.selectOne
### The error occurred while executing a query
### Cause: java.sql.SQLException: Access denied for user 
'guacamole_user'@'10.66.204.13' (using password: YES)


My guacamole.properties is:
# MySQL properties
mysql-hostname: 10.66.204.10
mysql-port: 3306
mysql-database: *
mysql-username: *
mysql-password: *
mysql-default-max-connections: 1000
mysql-default-max-group-connections: 1000


why it still access to mysql 10.66.204.13 and not the 10.66.204.10?



This message is telling you that the user is logging in *from* 10.66.204.13, 
presumably the host where Guacamole is running.  This just means that the MySQL 
user either doesn't have an entry for logging in from that host, or the 
credentials are incorrect.  Try logging in using the mysql-username and 
mysql-password values from a MySQL command line client on the same system where 
Guacamole is running.

-Nick


CONFIDENTIALITY NOTICE:

This electronic message is intended to be viewed only by the individual or 
entity to whom it is addressed. It may contain information that is privileged, 
confidential and exempt from disclosure under applicable law. Any 
dissemination, distribution or copying of this communication is strictly 
prohibited without our prior permission. If the reader of this message is not 
the intended recipient, or the employee or agent responsible for delivering the 
message to the intended recipient, or if you have received this communication 
in error, please notify us immediately by return e-mail and delete the original 
message and any copies of it from your computer system. For further information 
about Hikvision company. please see our website at 
www.hikvision.com<http://www.hikvision.com>

Re: POST /guacamole/api/tokens HTTP/1.1" 500

[Nick Couchman]

On Mon, Apr 1, 2019 at 8:47 AM Oliver.Zhang 
wrote:

> The tomcat error log is :
>
> ### Error querying database.  Cause: java.sql.SQLException: Access denied
> for user 'guacamole_user'@'10.66.204.13' (using password: YES)
>
> ### The error may exist in
> org/apache/guacamole/auth/jdbc/user/UserMapper.xml
>
> ### The error may involve
> org.apache.guacamole.auth.jdbc.user.UserMapper.selectOne
>
> ### The error occurred while executing a query
>
> ### Cause: java.sql.SQLException: Access denied for user 
> 'guacamole_user'@'10.66.204.13'
> (using password: YES)
>
>
>
>
>
> My guacamole.properties is:
>
> # MySQL properties
>
> mysql-hostname: 10.66.204.10
>
> mysql-port: 3306
>
> mysql-database: *
>
> mysql-username: *
>
> mysql-password: *
>
> mysql-default-max-connections: 1000
>
> mysql-default-max-group-connections: 1000
>
>
>
>
>
> why it still access to mysql 10.66.204.13 and not the 10.66.204.10?
>
>
>
>
>

This message is telling you that the user is logging in *from*
10.66.204.13, presumably the host where Guacamole is running.  This just
means that the MySQL user either doesn't have an entry for logging in from
that host, or the credentials are incorrect.  Try logging in using the
mysql-username and mysql-password values from a MySQL command line client
on the same system where Guacamole is running.

-Nick

答复: POST /guacamole/api/tokens HTTP/1.1" 500

[Oliver . Zhang]

The tomcat error log is :
### Error querying database.  Cause: java.sql.SQLException: Access denied for 
user 'guacamole_user'@'10.66.204.13' (using password: YES)
### The error may exist in org/apache/guacamole/auth/jdbc/user/UserMapper.xml
### The error may involve 
org.apache.guacamole.auth.jdbc.user.UserMapper.selectOne
### The error occurred while executing a query
### Cause: java.sql.SQLException: Access denied for user 
'guacamole_user'@'10.66.204.13' (using password: YES)


My guacamole.properties is:
# MySQL properties
mysql-hostname: 10.66.204.10
mysql-port: 3306
mysql-database: *
mysql-username: *
mysql-password: *
mysql-default-max-connections: 1000
mysql-default-max-group-connections: 1000


why it still access to mysql 10.66.204.13 and not the 10.66.204.10?




发件人: Mike Jumper [mailto:mjum...@apache.org]
发送时间: 2019年4月1日 20:33
收件人: user@guacamole.apache.org
主题: Re: POST /guacamole/api/tokens HTTP/1.1" 500

On Mon, Apr 1, 2019, 05:24 Oliver.Zhang 
mailto:zhangjianp...@hikvision.com>> wrote:
The error occurred : POST /guacamole/api/tokens HTTP/1.1" 500,  hwo to resolve 
it?

You will need to determine what error is occurring.

Check the Tomcat logs for error messages from Guacamole, some of which may have 
occurred much earlier during webapp startup. If you have a reverse proxy in 
front of Guacamole, check that, too.

- Mike



CONFIDENTIALITY NOTICE:

This electronic message is intended to be viewed only by the individual or 
entity to whom it is addressed. It may contain information that is privileged, 
confidential and exempt from disclosure under applicable law. Any 
dissemination, distribution or copying of this communication is strictly 
prohibited without our prior permission. If the reader of this message is not 
the intended recipient, or the employee or agent responsible for delivering the 
message to the intended recipient, or if you have received this communication 
in error, please notify us immediately by return e-mail and delete the original 
message and any copies of it from your computer system. For further information 
about Hikvision company. please see our website at 
www.hikvision.com<http://www.hikvision.com>

Re: POST /guacamole/api/tokens HTTP/1.1" 500

[Mike Jumper]

On Mon, Apr 1, 2019, 05:24 Oliver.Zhang  wrote:

> The error occurred : POST /guacamole/api/tokens HTTP/1.1" 500,  hwo to
> resolve it?
>

You will need to determine what error is occurring.

Check the Tomcat logs for error messages from Guacamole, some of which may
have occurred much earlier during webapp startup. If you have a reverse
proxy in front of Guacamole, check that, too.

- Mike

POST /guacamole/api/tokens HTTP/1.1" 500

[Oliver . Zhang]

The error occurred : POST /guacamole/api/tokens HTTP/1.1" 500,  hwo to resolve 
it?

简单 实用 优雅
-
技术开发组 张建平（zhangjianping）
TEL：0571-88075998-69364
---
本邮件及其附件含有海康威视公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from 
HIKVISION, which is intended only for  the person or entity whose address is 
listed above. Any use of the information contained herein in any way 
(including, but not limited to, total or partial disclosure, reproduction, or 
dissemination) by persons other  than the intended recipient(s) is prohibited. 
If you receive this e-mail in error, please notify the sender by phone or email 
immediately and delete it!



CONFIDENTIALITY NOTICE:

This electronic message is intended to be viewed only by the individual or 
entity to whom it is addressed. It may contain information that is privileged, 
confidential and exempt from disclosure under applicable law. Any 
dissemination, distribution or copying of this communication is strictly 
prohibited without our prior permission. If the reader of this message is not 
the intended recipient, or the employee or agent responsible for delivering the 
message to the intended recipient, or if you have received this communication 
in error, please notify us immediately by return e-mail and delete the original 
message and any copies of it from your computer system. For further information 
about Hikvision company. please see our website at 
www.hikvision.com<http://www.hikvision.com>

Re: Setting up HTTP header authentication

[Nick Couchman]

>
>
> 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

[Dmitry Katsubo]

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 
 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

[Nick Couchman]

>
> 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

[Dmitry Katsubo]

On 2019-03-22 01:54, Nick Couchman wrote:
> On Thu, Mar 21, 2019 at 8:38 PM Dmitry Katsubo  <mailto:dm...@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: HTTP head auth user setup

[Nick Couchman]

On Fri, Mar 22, 2019 at 10:45 AM Will Payne  wrote:

> On 2019-03-22 12:59, Nick Couchman wrote:
>
> > You're welcome to file a JIRA request for such a feature.
>
> Oh, I don't particularly care about simulating what a specific or
> unknown user would see - that's easy enough to test. I meant that it's a
> pain that you can't *set* what a pre-authenticated but undefined user
> will see. But yes, maybe I should file a request for *that* feature :)
>

Ah, yes - I think with user groups permissions like that became a bit
easier, because you can set the permissions for the group.  But I had also
thought about trying to implement some sort of "default permission"
configuration that would allow assigning permissions ahead of time to users
that aren't already defined.  I'm not sure that would necessarily make
sense today, because you have to explicitly create either users or groups
in the JDBC module before you can actually assign permissions to them.
With one of the changes underway, however, to auto-create JDBC users when
they are successfully authenticated elsewhere, this may make more sense.


>
> Am guessing adding LDAP into the mix is the only way forward.. Is there
> any rough expected date for 1.1.0? Not sure I want to battle to get it
> working just for the way it's implemented to change.
>

Soon-ish, hopefully.  Unfortunately the big blocker on it is getting
FreeRDP 2.0 support into the code, which is somewhat of a mountain of a
task.  Mike is knee-deep (or maybe neck-deep these days) in that.  Once
that gets completed, reviewed, and pushed through, the remaining changes
are reasonably light-weight and should be able to get reviewed relatively
quickly.


>
> I suppose the only other option at the moment is to revert to 0.9.14 and
> use the noauth extension.. At least that way I can easily, I assume, get
> everyone seeing the connections.
>
> > This is usually due to browser cache issues
>
> Ah - yep, I redeployed 1.0.0 and, after a bit of a kick, the browser
> shows the correct form headings.
>

There's a JIRA issue out there for this, too - there are ways to "version"
the static components such that they'll get refreshed when the version
changes, but it hasn't been implemented, yet.

-Nick

Re: HTTP head auth user setup

[Will Payne]

On 2019-03-22 12:59, Nick Couchman wrote:


You're welcome to file a JIRA request for such a feature.


Oh, I don't particularly care about simulating what a specific or 
unknown user would see - that's easy enough to test. I meant that it's a 
pain that you can't *set* what a pre-authenticated but undefined user 
will see. But yes, maybe I should file a request for *that* feature :)


Am guessing adding LDAP into the mix is the only way forward.. Is there 
any rough expected date for 1.1.0? Not sure I want to battle to get it 
working just for the way it's implemented to change.


I suppose the only other option at the moment is to revert to 0.9.14 and 
use the noauth extension.. At least that way I can easily, I assume, get 
everyone seeing the connections.



This is usually due to browser cache issues


Ah - yep, I redeployed 1.0.0 and, after a bit of a kick, the browser 
shows the correct form headings.


Ta,
W

Re: HTTP head auth user setup

[Nick Couchman]

On Fri, Mar 22, 2019 at 9:15 AM Will Payne  wrote:

>
> > Where are you storing connections?  I assume JDBC?
>
> I had to check (I just followed some quick instructions on setting it up
> on Docker) but it's in the mysql DB.
>
> Also hadn't noticed that groups were only there in 1.0.0 - I'd reverted
> to 0.9.14 because the settings menus in 1.0.0 were full of input headers
> showing things like "MANAGE_USER_GROUP.SECTION_HEADER_USER_GROUP |
> TRANSLATE" and I thought I would tackle one issue at a time :)
>

This is usually due to browser cache issues, so clearing your browser cache
should also take care of these things.

-Nick

Re: HTTP head auth user setup

[Will Payne]

Where are you storing connections?  I assume JDBC?


I had to check (I just followed some quick instructions on setting it up 
on Docker) but it's in the mysql DB.


Also hadn't noticed that groups were only there in 1.0.0 - I'd reverted 
to 0.9.14 because the settings menus in 1.0.0 were full of input headers 
showing things like "MANAGE_USER_GROUP.SECTION_HEADER_USER_GROUP | 
TRANSLATE" and I thought I would tackle one issue at a time :)


W

Re: HTTP head auth user setup

[Nick Couchman]

On Fri, Mar 22, 2019 at 8:54 AM Will Payne  wrote:

> > There's no way within Guacamole, itself, to "simulate" user
> > permissions for a particular/unknown user.  With the header
> > authentication module, though, it should be pretty easy to set up a
> > simulation environment - you can set up the module, then configure
> > your reverse proxy with some simple authentication that lets you put
> > in any number of users and see what happens as you authenticate with
> > each of them.
>
>
> Thanks. That's a pain.
>

You're welcome to file a JIRA request for such a feature.  I've seen other
pieces of software (Owncloud/Nextcloud come to mind) that have the ability
to simulate a particular user, and I don't think it would be terribly
difficult to come up with something like that for Guacamole, it just needs
a feature request and then someone to work on it :-).


>
> We do have an LDAP directory of users (but not passwords so the auth
> needs handling elsewhere). Is it possible to use the LDAP user/group
> info in conjunction with HTTP header auth?
>
>
Well, maybe - it depends.  User groups are new in Guacamole 1.0.0, and
there will be some tweaks to them in 1.1.0 to correct a couple of bugs and
also address some confusion in the way it is implemented.  I suspect in
1.0.0 it will not work as you'd like it to.

Where are you storing connections?  I assume JDBC?

-Nick

Re: HTTP head auth user setup

[Will Payne]

There's no way within Guacamole, itself, to "simulate" user
permissions for a particular/unknown user.  With the header
authentication module, though, it should be pretty easy to set up a
simulation environment - you can set up the module, then configure
your reverse proxy with some simple authentication that lets you put
in any number of users and see what happens as you authenticate with
each of them.



Thanks. That's a pain.

We do have an LDAP directory of users (but not passwords so the auth 
needs handling elsewhere). Is it possible to use the LDAP user/group 
info in conjunction with HTTP header auth?


W

Re: HTTP head auth user setup

[Nick Couchman]

On Fri, Mar 22, 2019 at 8:34 AM Will Payne  wrote:

>
> Hi,
>
> With the HTTP header authorisation extension, is there a way to set what
> connections an unknown user will see? Or of setting certain connections
> as 'public'?
>

There's no way within Guacamole, itself, to "simulate" user permissions for
a particular/unknown user.  With the header authentication module, though,
it should be pretty easy to set up a simulation environment - you can set
up the module, then configure your reverse proxy with some simple
authentication that lets you put in any number of users and see what
happens as you authenticate with each of them.

Also, there's no way within Guacamole currently to set a connection as
"public" or even at this point to set default permissions.  So, if you
haven't explicitly assigned permissions to a user or group of users, the
connection will not be automatically visible to new/unknown users.

-Nick

HTTP head auth user setup

[Will Payne]

Hi,

With the HTTP header authorisation extension, is there a way to set what 
connections an unknown user will see? Or of setting certain connections 
as 'public'?


Ta,
W

Re: Setting up HTTP header authentication

[Nick Couchman]

On Thu, Mar 21, 2019 at 8:38 PM Dmitry Katsubo  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
&g

Re: Setting up HTTP header authentication

[Dmitry Katsubo]

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 n

Re: Setting up HTTP header authentication

[Nick Couchman]

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
> <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  context, or multiple
> connections specified within their own  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

[brian mullan]

Maybe I missed it but what linux distro are you using ?

On Wed, Mar 20, 2019, 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?
> 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  context, or multiple
> connections specified within their own  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

[Dmitry Katsubo]

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?
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  context, or multiple connections 
> specified within their own
>  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

[Nick Couchman]

On Tue, Mar 19, 2019 at 7:56 PM Dmitry Katsubo  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:
>
> 
> 
> 
> vnc
> vncserver
> 5901
> secret
> UTF-8
> 
> 
> 
>
> 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  tag. This tag
> contains all authorized connections for that user, each denoted with a
>  tag.
>
> however one page before it provides an example where  tag not
> necessarily contains :
>
> 
> vnc
> localhost
> 5900
> VNCPASS
> 
>
> So what is the rule: should  contain s tags or can
> it also describe one connection?
>

The File provider handles both cases - either the single connection
specified within the  context, or multiple
connections specified within their own  contexts.

-Nick