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 <skraw...@ithnet.com> wrote: > On Sat, 20 Apr 2024 21:38:20 -0400 > Nick Couchman <vn...@apache.org> 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. This can be > > done, today, using something like fail2ban, but it'll be a bit more > > integrated and easy with the extension. > > * Write another authentication extension that either allows or disallows > > authentication based on IP address or CIDR range. > > * The guacamole-auth-header extension also allows you to perform your > > authentication using some other means - like a front-end web proxy (Nginx > > or httpd) and then provide a way to pass that authentication information > > through to Guacamole in such a way that Guacamole trusts that the > username > > being provided has actually been authenticated. This also might help > > accomplish something closer to the original goal - for example, you could > > put Apache httpd in front of Guacamole, configure httpd to do LDAP > > authentication but also configure it with certain allowed and/or denied > IP > > addresses or IP ranges, and then use the guacamole-auth-header extension. > > > > -Nick > > Nick, see your whole, quite lengthy in-depth answer and understand how > complicated and long you are making something that is in fact really a > 5-liner > script. > I am really not interested in deploying servers of all kinds - not even an > ldap server. I only used ldap because it has a hook for a script. Only I > don't > get an IP address there. Configuring a whole Radius-Server just to get > hands > on an IP the caller (i.e. guacamole) has right in "its hands" is perfect > overkill. And there is no security problem at all, as the hook script runs > on > the guacamole box anyway. We don't have to do remote IP/TCP sessions > anywhere. > We don't get intercepted. If your guacamole box is compromised then your > authentication is anyway. So where is the point? > And one last thing: even the hyped REST API is nothing more than a point in > the queue _after_ my proposed hook. Because it talks to some server-service > and deals with things that are already far above the true basic question: I > have this information (username, PW, IP, date, whatever), how is your > answer? > Why should I even bother to ask someone what he wants for his idea of > authentication? > I just hand over what I have and let him decide what he wants to use. > Because > as guacamole I really shouldn't be interested, because it is not my basic > function. He should be perfectly capable of ignoring parameters he does not > need. > If then someone wants to interface to an entity that plays REST API, then > lets > make a hook for a REST API. And if I don't need that at all (like in my > application) I don't have to go through this whole bloatware. > > God, look at your explanation of 1.6.0. Now you're already beginning to > deal > with interfacing for banning IPs, not seeing you are only inventing the > wheel > for the 10th time already... > Ever heard of "keep it simple" ? > I am really sorry that this all sounds so bad and impolite, since you seem > a > very nice guy. But myself being a non-native english-speaking person I > don't > know a better way to say "please wake up, you are going down the wrong > track > and try to fix problems that are not there or are not your core business". > > If you really have a lot of spare programmer time in the project then jump > on > this (from your web): > "I want to print to my local printer. I see Guacamole has printing > support, but > this produces a PDF download. How do I print directly to my local > printers?" > Because printing locally works in Nextcloud/Collabora (office) setup > perfectly > and people compare that to a remote desktop via guacamole which cannot. > Don't come around with the weak explanation that RDP (or whatever) cannot > achieve this, because it is in fact your _core_ business to achieve this > function, whereas it is only finger-play to fiddle around with IP banning. > So > if some protocol like RDP does not what you need to fullfill your projects > basic feature list, then go and enhance that. > -- > Regards, > Stephan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org > For additional commands, e-mail: user-h...@guacamole.apache.org > >
