Re: How to get client IP address ?
On Sat, 20 Apr 2024 21:38:20 -0400 Nick Couchman wrote: > > > > Hello Nick, > > > > first of all, thank you for looking into the issue. So please let me ask > > this > > as a real question and no offence. > > > > None taken, perfectly fine to ask this. > > > > Why does the project _at all_ use a rather complicated API for > > authentication > > instead of "outsourcing" the function into a simple called hook (call it a > > script), and let this implement the wanted api to ldap, mysql, radius or > > just > > about anything that might be needed. > > > This is what we already do. Yes, the entire web-based application works > through a REST API, but, on the back-end, we take the REST API calls and > feed them, through a set of standard interfaces, to a back-end > authentication mechanism. The back-end authentication mechanisms are > standardized, interchangeable and stackable - you can use one or more in > combination, or you can write your own. The mechanisms can also "decorate" > other ones, so that you can use a back-end mechanism (like JDBC), but > extend its functionality to do something else. > > > > Still in the end an authentication is no > > more than giving parameters (like username, password, or client ip or > > whatever the caller (i.e. guacamole) has) and getting the simple answer: > > yes > > (authenticated) or no (login failed). > > > > This is really what the REST API does - it allows the front-end web > application to 1) receive a list of requirements from the back-end > authentication mechanism, 2) provide those requirements, either > automatically (client IP) or by user input (username and password), 3) get > an answer about whether authentication has succeeded or not, and 4) receive > and process data that the client has been authorized to receive (in our > case, connections, connection groups, users, groups, etc.). > > > > If you cut off the whole process at this point the whole story gets a lot > > more > > flexible, as anyone can then implement his needed hook (script) for his > > needs. > > > > As mentioned above, this is exactly how it works with the authentication > extensions. > > > > You may then distribute such hooks inside the project for standard APIs > > like > > ldap or the like - or leave it to the users to make/find their own. > > > > Yep, and Guacamole's design allows for exactly this - and the REST API does > not get in the way of that, in fact, it makes it possible to do that > without having to change the front-end web application at all. > > Also, none of the things you've mentioned actually address the issue you've > originally raised - no matter what method you use to communicate between > the web browser and the server, you still need to be able to provide the > data you're interested in providing - IP address, username, and password - > to the authentication system (LDAP you specifically mentioned). Unless your > solution is to have the client authenticate to LDAP directly and then > somehow tell the server that it is authenticated - which has a lot of > security risks to it (how does the server know to trust the client when it > says it authenticated successfully?) - I don't know of a way, with *LDAP* > specifically, to have the client IP address be part of the authentication > process, regardless of the language (PHP, ldapsearch, Java/JSP, > CGI/Perl...etc.). RADIUS, as a protocol, has those things built into it - > the NAS IP field within a RADIUS authentication request allows you to pass > the client IP on to the RADIUS server and then allow the RADIUS server to > make a determination about authentication success or failure based on that > in combination with the other information asked and provided (RADIUS > secret, username, password, one-time-password, etc.). > > So does Kerberos - in fact, Kerberos actually does exactly what is > mentioned above - establishes a trusted relationship between KDC, > Server/Service, and Client, such that the client can authenticate and then > reliably tell the server that it should trust the client because they share > information that makes it trustworthy. And so Kerberos also has a way of > factoring the client system into the authentication process, in addition to > the username and password. At some point I will probably take a crack at a > Kerberos extension or configuration that does this, which also allows for > doing very seamless authentication with no need for entering credentials if > you're already logged into a client where you have a valid Kerberos ticket. > > If you're also just looking for a way to factor a client IP address into > the authentication process, but it doesn't have to be linked directly to > the username or password, there are ways to do that, as well: > * Have a front-end proxy or Web Application Firewall filter based on IP > address. > * The 1.6.0 version of Guacamole Client will have an extension that allows > for banning IP addresses that repeatedly fail authentication
Re: How to get client IP address ?
I'll keep this response shorter. It seems unlikely we're going to come to an understanding or agreement on how Guacamole should be implemented. The great thing is that Guacamole is open source, and it sounds like you have some software development experience, so you can fork the source code and modify it to suit your needs and design philosophy, and even contribute that code back to the community, if you're so inclined. -Nick On Sun, Apr 21, 2024 at 3:55 AM Stephan von Krawczynski wrote: > On Sat, 20 Apr 2024 21:38:20 -0400 > Nick Couchman wrote: > > > > > > > Hello Nick, > > > > > > first of all, thank you for looking into the issue. So please let me > ask > > > this > > > as a real question and no offence. > > > > > > > None taken, perfectly fine to ask this. > > > > > > > Why does the project _at all_ use a rather complicated API for > > > authentication > > > instead of "outsourcing" the function into a simple called hook (call > it a > > > script), and let this implement the wanted api to ldap, mysql, radius > or > > > just > > > about anything that might be needed. > > > > > > This is what we already do. Yes, the entire web-based application works > > through a REST API, but, on the back-end, we take the REST API calls and > > feed them, through a set of standard interfaces, to a back-end > > authentication mechanism. The back-end authentication mechanisms are > > standardized, interchangeable and stackable - you can use one or more in > > combination, or you can write your own. The mechanisms can also > "decorate" > > other ones, so that you can use a back-end mechanism (like JDBC), but > > extend its functionality to do something else. > > > > > > > Still in the end an authentication is no > > > more than giving parameters (like username, password, or client ip or > > > whatever the caller (i.e. guacamole) has) and getting the simple > answer: > > > yes > > > (authenticated) or no (login failed). > > > > > > > This is really what the REST API does - it allows the front-end web > > application to 1) receive a list of requirements from the back-end > > authentication mechanism, 2) provide those requirements, either > > automatically (client IP) or by user input (username and password), 3) > get > > an answer about whether authentication has succeeded or not, and 4) > receive > > and process data that the client has been authorized to receive (in our > > case, connections, connection groups, users, groups, etc.). > > > > > > > If you cut off the whole process at this point the whole story gets a > lot > > > more > > > flexible, as anyone can then implement his needed hook (script) for his > > > needs. > > > > > > > As mentioned above, this is exactly how it works with the authentication > > extensions. > > > > > > > You may then distribute such hooks inside the project for standard APIs > > > like > > > ldap or the like - or leave it to the users to make/find their own. > > > > > > > Yep, and Guacamole's design allows for exactly this - and the REST API > does > > not get in the way of that, in fact, it makes it possible to do that > > without having to change the front-end web application at all. > > > > Also, none of the things you've mentioned actually address the issue > you've > > originally raised - no matter what method you use to communicate between > > the web browser and the server, you still need to be able to provide the > > data you're interested in providing - IP address, username, and password > - > > to the authentication system (LDAP you specifically mentioned). Unless > your > > solution is to have the client authenticate to LDAP directly and then > > somehow tell the server that it is authenticated - which has a lot of > > security risks to it (how does the server know to trust the client when > it > > says it authenticated successfully?) - I don't know of a way, with *LDAP* > > specifically, to have the client IP address be part of the authentication > > process, regardless of the language (PHP, ldapsearch, Java/JSP, > > CGI/Perl...etc.). RADIUS, as a protocol, has those things built into it - > > the NAS IP field within a RADIUS authentication request allows you to > pass > > the client IP on to the RADIUS server and then allow the RADIUS server to > > make a determination about authentication success or failure based on > that > > in combination with the other information asked and provided (RADIUS > > secret, username, password, one-time-password, etc.). > > > > So does Kerberos - in fact, Kerberos actually does exactly what is > > mentioned above - establishes a trusted relationship between KDC, > > Server/Service, and Client, such that the client can authenticate and > then > > reliably tell the server that it should trust the client because they > share > > information that makes it trustworthy. And so Kerberos also has a way of > > factoring the client system into the authentication process, in addition > to > > the username and password. At some point I will probably
Re: How to get client IP address ?
Hi Joachim, I fail to see how your application invalidates my request for a minimal reorganisation of the whole authentication setup. My basic criticism is not that guacamole can do something (or a lot of things) itself. I am only not seeing a basic design that allows _simple_ setups as well as extensions not seen today. All I am telling is I would very much prefer a simple interface that parts the core guacamole from such extensions (of authentication or your type) in a way that the most basic function (user authentication) can be done in the most simple way. And although everything is very complex now even Nick seems unable to portray a simple way to authenticate a n-tuple (username,pw,ip). And I might well assume he knows guacamole very indepth. -- Regards, Stephan On Sun, 21 Apr 2024 08:16:54 +0200 "Joachim Lindenberg" wrote: > Hi Stephan, > I´d agree if authentication were the only goal of the API. However it also > allows to authorize users, and to provide (including create) configuration > data entirely not in the standard database. I visualized that capability and > how I use it in > https://software.lindenberg.one/backup/en/documentation/guacamole-integration. > I am not telling it cannot be done differently, but asking just for > authentication is too limiting. Regards, Joachim > > -Ursprüngliche Nachricht- > Von: Stephan von Krawczynski > Gesendet: Sonntag, 21. April 2024 00:16 > An: user@guacamole.apache.org > Betreff: Re: How to get client IP address ? > > On Sat, 20 Apr 2024 15:52:58 -0400 > Nick Couchman wrote: > > > > > > > > > > > I believe the issue that Stephan is describing is that, when the > > > > user > > > logs > > > > in to Guacamole, and the remote LDAP server that is authenticating > > > > the > > > user > > > > logs a client IP address, it should log the IP address of the > > > > browser > > > (far > > > > end client) and not the IP address of the Guacamole Client > > > > (tomcat) > > > system. > > > > I'm just trying to get clarity from Stephan on whether this is > > > > what he's actually trying to do and why. > > > > > > > > -Nick > > > > > > Yes, Nick, you are exactly on the right track here. And I am really > > > not in a logging question, but truely in the authentication process > > > where I want to know the far end client. > > > > > > > > After looking at this a bit more, I cannot find a way, at least in the > > Apache LDAP API that we use, to configure a client IP or send any sort > > of a message that will pass that information through to the client, so > > I'm not sure how feasible this actually is. RADIUS uas the NAS IP > > designed specifically for this type of scenario, but I'm not finding > > any sort of feature similar to NAS IP that allows for this kind of > > messaging. > > > > -Nick > > Hello Nick, > > first of all, thank you for looking into the issue. So please let me ask > this as a real question and no offence. Why does the project _at all_ use a > rather complicated API for authentication instead of "outsourcing" the > function into a simple called hook (call it a script), and let this > implement the wanted api to ldap, mysql, radius or just about anything that > might be needed. Still in the end an authentication is no more than giving > parameters (like username, password, or client ip or whatever the caller > (i.e. guacamole) has) and getting the simple answer: yes (authenticated) or > no (login failed). If you cut off the whole process at this point the whole > story gets a lot more flexible, as anyone can then implement his needed hook > (script) for his needs. You may then distribute such hooks inside the > project for standard APIs like ldap or the like - or leave it to the users > to make/find their own. To me, designing (and coding) software since the > 1980s, this is a pretty clear design decision to be taken. > > Regards, > Stephan > > - > To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org > For additional commands, e-mail: user-h...@guacamole.apache.org > > > > - > To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org > For additional commands, e-mail: user-h...@guacamole.apache.org > - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Re: How to get client IP address ?
On Sun, 21 Apr 2024 07:12:36 -0400 Nick Couchman wrote: > I'll keep this response shorter. > > It seems unlikely we're going to come to an understanding or agreement on > how Guacamole should be implemented. The great thing is that Guacamole is > open source, and it sounds like you have some software development > experience, so you can fork the source code and modify it to suit your > needs and design philosophy, and even contribute that code back to the > community, if you're so inclined. > > -Nick You're right in that manner that I am not the type of guy that stops what he is doing only because code is in the way. Still you should be aware that I am not forking such a monster only to change few lines of code in it. You may get/see some patch from me to achieve what I want to do with guacamole, and I expect it to be ignored. I take it as documented then and it may help further readers along their way. Often people deny to see how they can make a very good product out of their mediocre one, unfortunately. -- Regards, Stephan - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Re: How to get client IP address ?
Stephan, Having been around here for a while I'd be very surprised to find code contributions simply 'ignored'. If you look at Guacamole's development history I think you'd see that contributions are welcomed, and where they address a need and/or fit the project well they are incorporated. Naturally there would be discussion, and it *may* be that some contributions are not [immediately] accepted, however they would not be discarded out of hand for no reason. Perhaps this has been your experience of other projects but please don't anticipate it here. Otherwise it's my view (and clearly that of many others) that Guacamole is not a 'mediocre' product. It has its flaws and no doubt could be improved, but being derogatory about something is not especially productive and rarely a good way to effect change. Thus I wonder if you might spend a little time looking closely at Guacamole's development and how/why it works the way it does presently? As an active project with good interaction and hard working developers, input from experienced coders would be gratefully received. However I suggest the usual way to go about changing something is first to become involved, become 'known' by your contributions, to gain better knowledge of the issues and direction facing the project, and thence be able to effect positive and cohesive change... On 22/04/24 08:06, Stephan von Krawczynski wrote: You may get/see some patch from me to achieve what I want to do with guacamole, and I expect it to be ignored. I take it as documented then and it may help further readers along their way. Often people deny to see how they can make a very good product out of their mediocre one, unfortunately. - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Re: Installing Guacamole 1.5.5 tomcat listener failed to start
Hi Willy, TLDR: Many Many thanks for the crazy-fast reply - tomcat 9 to the rescue, so much easier this way :-) I will SSL it up and go from there. Longer Version: Such a winding road related to balancing linux distro, certbot, java, tomcat and guacamole, but for better or worse, looks like I am close to crossing the finish line with Alma 8, Java 11, Tomcat 9 (thank you again), and Guacamole 1.5.5. I was tempted to try the one-off Jakarta refresh in that ticket, tempted, but I didn't do it. All the best, Ted On Saturday, April 20th, 2024 at 11:10 PM, Willy Manga wrote: > > > Hi, > > On 21/04/2024 06:47, My Data Belongs to Me! wrote: > > > Hello, > > I am running Alma 8, and followed the these instructions to get Guacamole > > installed and running: > > https://guacamole.apache.org/doc/gug/installing-guacamole.html > > when things were not working (guacd would run and exit, tomcat would not > > unpack any wars at all), I then reviewed these > > https://idroot.us/install-apache-tomcat-almalinux-8/ > > https://idroot.us/install-apache-guacamole-almalinux-8/ > > > > Funny. I just learnt in my last thread that guacamole does not work on > tomcat10. Check work in progress here [1][2] . > I doubt this documentation is right. > > 1. https://issues.apache.org/jira/browse/GUACAMOLE-1325 > 2. https://github.com/apache/guacamole-client/pull/972 > > > and I have gotten to the point where tomcat is running and reachable, the > > war unpacks, guacd is running, but catalina.out still reports: > > " > > 21-Apr-2024 02:29:31.065 SEVERE [main] > > org.apache.catalina.core.StandardContext.startInternal One or more > > listeners failed to start. Full details will be found in the appropriate > > container log file > > 21-Apr-2024 02:29:31.088 SEVERE [main] > > org.apache.catalina.core.StandardContext.startInternal Context [/guacamole] > > startup failed due to previous errors > > " > > I tried syslog, but this VPS doesn't appear to have that. > > > I guess you are using systemd. Thus, you can check the logs with > > journalctl --system > > -- > Willy Manga > > > - > To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org > For additional commands, e-mail: user-h...@guacamole.apache.org - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Re: Installing Guacamole 1.5.5 tomcat listener failed to start
On Sun, Apr 21, 2024 at 9:56 PM My Data Belongs to Me! < i...@mydatabelongsto.me> wrote: > Hi Willy, > > TLDR: > Many Many thanks for the crazy-fast reply - tomcat 9 to the rescue, so > much easier this way :-) I will SSL it up and go from there. > > Longer Version: > Such a winding road related to balancing linux distro, certbot, java, > tomcat and guacamole, but for better or worse, looks like I am close to > crossing the finish line with Alma 8, Java 11, Tomcat 9 (thank you again), > and Guacamole 1.5.5. > > Running in Docker may be a route you could go if you find managing that too complex. It has its own complexities, to be sure, but abstracts away at least the build process. > I was tempted to try the one-off Jakarta refresh in that ticket, tempted, > but I didn't do it. > > Yeah, I'm not sure it's quite ready for use, yet - I'd appreciate people testing it, but wouldn't recommend it for any real use at the moment. -Nick
Re: How to get client IP address ?
On Sun, Apr 21, 2024 at 5:18 PM Ivanmarcus wrote: > Stephan, > > Having been around here for a while I'd be very surprised to find code > contributions simply 'ignored'. If you look at Guacamole's development > history I think you'd see that contributions are welcomed, and where > they address a need and/or fit the project well they are incorporated. > > Naturally there would be discussion, and it *may* be that some > contributions are not [immediately] accepted, however they would not be > discarded out of hand for no reason. Perhaps this has been your > experience of other projects but please don't anticipate it here. > > Yes, completely agree. There is definitely scrutiny of changes and discussion around it, and a rather robust review process. So, while changes will not be discarded out of hand, for no reason, they will also not be blindly accepted. > Otherwise it's my view (and clearly that of many others) that Guacamole > is not a 'mediocre' product. It has its flaws and no doubt could be > improved, but being derogatory about something is not especially > productive and rarely a good way to effect change. > > Thus I wonder if you might spend a little time looking closely at > Guacamole's development and how/why it works the way it does presently? > As an active project with good interaction and hard working developers, > input from experienced coders would be gratefully received. However I > suggest the usual way to go about changing something is first to become > involved, become 'known' by your contributions, to gain better knowledge > of the issues and direction facing the project, and thence be able to > effect positive and cohesive change... > > +1 I would love to see the community of active contributors, both developers and supporters on the mailing list, grow to include a greater number and more diverse population. -Nick
